The serving route checked the blocklist per request but not
attachmentConfineToWorkspace, while the attachment serve path
(file-routes.ts) re-checks it every time. A capability minted for a
folder outside the workspace before an admin turned confinement on kept
serving that folder for the rest of its TTL.
The capability record now says whether its folder was admitted from
outside the workspace, and the serving route refuses such a record while
confinement is on. The flag is part of the reuse key, so an
out-of-workspace mint never picks up a capability recorded as
in-workspace for the same folder.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Clicking an agent's `.html` path showed source text or downloaded it, so a
generated report could only be viewed by asking the agent to start a web
server. Render it instead, without serving HTML same-origin:
- POST /api/sessions/:id/html-view mints a capability for the file's own
directory (workspace path, or outside it under the attachment guard).
- GET /html-view/:cap/* serves the page and its relative assets with
`Content-Security-Policy: sandbox` WITHOUT allow-same-origin, so the page
runs in an opaque origin (also as a top-level tab) and cannot read the
Codeman document, its cookies or its API.
- Served files: non-dot, asset-allowlisted, realpath-confined to that
directory, blocklist applied; GET only. Capabilities are memory-only with a
rolling TTL and are revoked with the web-tab ones on logout.
- Frontend: the file preview renders HTML in a sandboxed iframe (popout opens
the same URL); terminal `.html` links go to the preview, not the log viewer.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Codeman maintainer