--- title: "Workspace Grants bound PersonaBot file access" version: "en" --- > Documentation Index > Fetch the complete documentation index at: https://botharness.ai/llms.txt > Use this file to discover all available pages before exploring further. # Workspace Grants bound PersonaBot file access > Status: Accepted # Workspace Grants bound PersonaBot file access ADR-0048 made a Workspace Grant the durable authority for admitting one-cwd Assignments. Human QA then showed that an Orchestrator could use native bash and read to inspect a project file after its Grant was revoked: DSH workspace-write governs writes under one Session cwd and backend temp area but does not isolate reads. A visible list of granted folders therefore cannot truthfully mean file access unless every file-capable operation honors it. ## Decision The application-defined Workspace Grant is PersonaBot-scoped file authority for the default-safe mode. A valid Grant lets the Orchestrator **read** its resolved project directory. The Orchestrator may directly **write only its Memory Repository**, which remains its fixed cwd and an implicit, non-revocable internal root. To change project files, it creates an independent Assignment with one selected active Grant. That Assignment may read and write that one project directory; it does not inherit the Orchestrator's other Grants or Memory root. DSH Workspace registration identifies and resolves a directory; it is not authorization. A Human adds an existing Host folder through the DSH picker or an absolute path entry validated by the DSH Workspace registry, then grants it to one PersonaBot. Removing a folder from that Bot's active access list revokes the Grant; it never deletes the host directory, DSH registration, or historical Assignment snapshot. A new Grant does not reactivate a Session bound to an older revoked Grant. BotHarness checks the effective read and write roots for path-addressed native file and search tools at DSH's final Tool guard. An opaque tool such as Shell or terminal cannot prove its file effects from arguments alone. Before one such call executes, BotHarness uses the DSH `tools/pre-execute` and `approval/request` seams to pause that exact call and show its full input in the PersonaBot DM. A Human may allow it once or reject it; missing, cancelled, or unpresentable approval fails closed. The Orchestrator may run only a literal `ls -la` or `pwd` in its canonical Memory working directory without approval; argument-bearing, redirected, background, or other Shell calls remain opaque and use the approval flow. One-time approval is an explicit exception to Grant-scoped file access: the approved program may reach outside the listed folders, so the UI must state that risk. This is not equivalent to a confined Execution World Provider. DSH workspace-write remains the native Session mode but is not itself evidence of read isolation or of Memory-only writes; backend temp paths must not bypass the BotHarness boundary. Path identity is canonicalized in the Host execution world. Revocation blocks future capability calls from both roles and future Assignment create/request/resume/wake. A call that passed the boundary before revocation may settle; the UI must say that a running item does not stop automatically and must not imply that already observed content is erased from Session history. The Human-facing right pane shows Memory as a fixed internal row and active granted folders as removable read-access rows, with an Add folder action. Revoked records remain available as history, not duplicate active rows. A Human may save a BotHarness Tool Approval Rule from a paused Channel approval card. The exact rule matches the full native tool name and serialized input; the broader rule covers all opaque native tools for that Bot, root role, and current Grant scope. Neither rule grants a Workspace, changes DSH's native tool body, or silently approves a different Bot. Each matching call still enters DSH `approval/request` and receives `allowed-once`, preserving per-call Session audit. Revoking the rule stops the next matching call; changing or revoking the Grant changes the scope and invalidates the former match. Command regex and inferred similarity are deferred until a Human can inspect and edit an explicit pattern. Each PersonaBot also has a Human-controlled Assignment Access Preset. The safe default creates new Assignments with DSH `workspace-write + ask`. Explicit dangerous opt-in creates subsequent Assignments with DSH `danger-full-access + never`, bypassing BotHarness file-path and opaque-tool gates after the selected Grant and Session snapshot are checked. The Orchestrator stays in the safe mode, and existing Assignments retain their frozen mode. The UI requires a separate risk confirmation and keeps an active warning visible. Turning the preset off affects new Assignments only; revoking an Assignment's Grant still stops its future calls. ## Scope and trade-offs This narrows the Human's earlier proposal that the Orchestrator directly read and write every granted folder. Project writes remain attributable to one Assignment and its single Grant. It supersedes ADR-0048's implication that Orchestrator access is confined merely by Memory cwd; ADR-0048's one-Grant-per-Assignment and durable provenance decisions remain. The dangerous Assignment preset explicitly bypasses default-safe filesystem confinement. It is not Grant-scoped file confinement: the Grant remains required for Assignment identity and revocation, while the opted-in Session may access outside its folder. Separate Human confirmation and persistent risk labeling are required. Orchestrator never inherits that preset. A multi-root writable Orchestrator and a multi-cwd Assignment remain outside this decision. ## First enforced slice The pinned DSH filesystem and sandbox providers confine writes but allow reads outside the Session cwd. BotHarness therefore uses DSH's final `ctx.tools.guard()` before tool dispatch to enforce path-addressed file access; inherited native tools stay visible so opaque calls can enter the Human approval flow. DSH's existing `read`, `read_image`, `write`, `edit`, `str_replace_editor`, `glob`, and `grep` remain available; the guard checks their path arguments against current Grant authority on every call. A revoked Grant blocks the next native file call, including a call in an already-running turn. Ordinary DSH Sessions keep their own capabilities. The guard resolves existing paths and new-file parents in the Host, rejects symlink escapes, and checks canonical containment. Orchestrator read roots are Memory plus currently active Grants, while its only write root is Memory. An Assignment uses its original Grant ID and one directory for both reads and writes; reauthorization creates a new Grant and cannot revive an old Assignment. A local process concurrently changing symlinks can race the in-process path check, matching the current DSH filesystem provider threat model; this slice is an Agent capability boundary, not a hostile same-user process sandbox. The next tracer restores inherited native capabilities for Bot-owned Sessions. Path-checkable file calls keep automatic Grant validation; opaque calls enter a DSH one-time Human approval flow and retain their native tool body. The approval answerer is application-defined Channel UI, while DSH owns the `approval/asked` and `approval/decided` Session audit events. The final Tool guard checks the current Session/Grant again after approval and consumes an approval token bound to the exact invocation. Revocation still blocks an Assignment call before dispatch, but it cannot undo a call that already started. Native `run_code` availability depends on the Agent's DSH tool presentation mode and requires runtime verification; this decision does not claim that every optional provider is installed. Source: https://botharness.ai/dev/adr/0067-workspace-grants-bound-personabot-file-access/index.mdx