webdav

concepts / webdav · ← concepts

Each group folder is exposed over WebDAV at https://<host>/dav/<group>/. You can mount it from Finder, sync it with rclone, or edit a file in any editor — and the next agent turn picks up your changes. Step-by-step setup: how-to / webdav.

what davd does

The davd daemon is a thin wrapper around sigoden/dufs — one Rust binary that serves a directory over WebDAV. It mounts <data-dir>/groups/ at /data inside its container and exposes it on :8080. That’s the whole daemon.

davd has no idea who you are. Authentication and per-group scoping happen one hop earlier, in proxyd.

why it matters

The same folder you see over WebDAV is the folder the agent reads each turn. Edit CLAUDE.md from your laptop, save, send the agent a message — the new runbook is already in effect. No deploy, no restart. Drop a CSV in facts/, the agent finds it on the next recall.

show me

# list a group's files with curl + PROPFIND
curl -X PROPFIND https://<host>/dav/<group>/ \
     -H 'Depth: 1' \
     -H "Authorization: Bearer $TOKEN"

# mount it as a real filesystem
rclone mount mygroup:/dav/<group>/ ~/mnt/<group> --vfs-cache-mode writes

# now edit a file like any other
vim ~/mnt/<group>/CLAUDE.md

Get $TOKEN from /dash/profile. Browsers can sign in at /auth/login and use the JWT cookie instead.

auth: proxyd in front

Every /dav/<group>/... request hits proxyd first. proxyd verifies the JWT (cookie or Bearer token), reads the user’s groups claim, and checks the <group> in the URL against that claim. No match, no upstream — 403 before davd sees the request. Operators with the ** grant reach any folder.

the write-block guard

Even with a valid grant, proxyd refuses writes to a few paths inside the group folder. Reads still pass through — the operator can always inspect.

what you get

go deeper