← Back to PRs

#19344: fix(sandbox): allow writes when workspaceAccess is 'none'

by mingming099 open 2026-02-17 18:10 View on GitHub →
agents size: XS
## Summary The `fs-bridge.ts` `allowsWrites()` and `fs-paths.ts` writable flags only returned `true` for `workspaceAccess='rw'`, but `pi-tools.ts` uses `workspaceAccess !== 'ro'` to determine if writes should be allowed. ## The Bug When `workspaceAccess='none'`: 1. `pi-tools.ts` correctly creates sandboxed write tools (because `allowWorkspaceWrites = sandbox?.workspaceAccess !== "ro"` is `true`) 2. But `fs-paths.ts` sets `writable: false` for the mount (because `workspaceAccess === "rw"` is `false`) 3. And `fs-bridge.ts` blocks the write at execution time (because `allowsWrites("none")` returns `false`) Result: Error message `Sandbox path is read-only; cannot create directories: /workspace` ## The Fix Changed both files to match the logic in `pi-tools.ts`: **fs-bridge.ts:** ```typescript // Before return access === "rw"; // After return access !== "ro"; ``` **fs-paths.ts** (lines 97 and 109): ```typescript // Before writable: sandbox.workspaceAccess === "rw", // After writable: sandbox.workspaceAccess !== "ro", ``` This allows writes for both `'rw'` and `'none'`, only blocking for `'ro'`. ## Test Scenario 1. Set `sandbox.workspaceAccess: "none"` in agent config 2. Run in sandboxed mode 3. Try to write a file: `write /workspace/test.txt` 4. **Before fix:** Error - `Sandbox path is read-only; cannot create directories: /workspace` 5. **After fix:** Works correctly - writes to sandbox temp workspace ## Files Changed - `src/agents/sandbox/fs-bridge.ts`: 1 function (allowsWrites) - `src/agents/sandbox/fs-paths.ts`: 2 locations (writable flags) <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a bug where `workspaceAccess: "none"` sandboxes incorrectly blocked write operations. Two files are updated to change the write-permission check from `=== "rw"` to `!== "ro"`, aligning with the existing logic in `pi-tools.ts` (line 282: `sandbox?.workspaceAccess !== "ro"`). **Changes:** - `fs-bridge.ts`: `allowsWrites()` now returns `true` for both `"none"` and `"rw"` access modes, blocking only `"ro"`. - `fs-paths.ts` (line 97): Primary workspace mount's `writable` flag corrected — this is the root cause of the reported error (`Sandbox path is read-only; cannot create directories: /workspace`). - `fs-paths.ts` (line 109): Agent workspace mount `writable` flag updated for consistency, though this branch is guarded by `workspaceAccess !== "none"` so the change has no runtime effect for the `"none"` case. The fix is semantically correct and consistent with how `docker.ts` mounts the workspace (no `:ro` suffix for `"none"` mode). No new regression tests are included to cover the `workspaceAccess: "none"` write scenario. <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — the logic change is minimal, correct, and consistent with existing patterns in the codebase. - The fix aligns two isolated helper functions (`allowsWrites` and the `writable` mount flags) with the already-correct logic in `pi-tools.ts`. The change is a simple two-value inversion (`=== "rw"` → `!== "ro"`) with clear, documented semantics: only `"ro"` should block writes. The `docker.ts` container-creation code already mounts the workspace as writable for `"none"` mode, so the fix restores consistency across the sandbox layer. The only gap is the absence of a regression test. - No files require special attention, though `src/agents/sandbox/fs-bridge.test.ts` would benefit from a new test case covering `workspaceAccess: "none"` writes. <sub>Last reviewed commit: 0cd97d4</sub> <!-- greptile_other_comments_section --> <sub>(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!</sub> <!-- /greptile_comment -->

Most Similar PRs