Skip to content

fix(sandbox): let an agent write in the project it was hired to work in - #591

Open
snehithareddy28 wants to merge 2 commits into
HarnessMD:mainfrom
snehithareddy28:fix/sandbox-allows-project-cwd
Open

snehithareddy28 wants to merge 2 commits into
HarnessMD:mainfrom
snehithareddy28:fix/sandbox-allows-project-cwd

Conversation

@snehithareddy28

Copy link
Copy Markdown
Contributor

What & why

Closes #449. Since v0.4.6 a spawned agent cannot write inside its own assigned project cwd. Every Bash command that writes there — git commits and merges, build output, rm, test artifacts — fails with Operation not permitted, and the only way through is disabling the Bash sandbox per command, which gives up the whole layer to get any work done. Read-only commands are unaffected, which is why this presents as a broken agent rather than as a sandbox.

The per-agent settings file declares sandbox.filesystem.allowWrite as the paths besides cwd — the agent's own hive folder, the hive root, the palace. The comment in hive.ts says so, and it was written on real evidence: verified live against claude 2.1.239, bypass mode still wrote cwd itself. That no longer holds. Once allowWrite is present it is the whole answer, so the one directory the agent was pointed at became the one directory it could not write.

The fix names cwd in the list. It costs nothing where it was already implied, and restores the agent's workspace where it is not.

What this deliberately does not do:

  • It does not widen the sandbox. The agent could always read cwd, and it is the single directory the agent was hired to work in. Everything outside these paths stays denied — touch $HOME/x still fails, which is the property the sandbox was turned on for.
  • It does not change the gate. The block is still emitted only when the caller asks for a sandbox, so an agent spawned without one stays exactly as unsandboxed as before.
  • It keeps both layers. allowWrite governs Bash children and permissions.additionalDirectories governs the Edit/Write tools; with only one the agent deadlocks on its own inbox, as the existing comment records.

Type of change

  • Bug fix
  • New feature
  • Refactor / cleanup
  • Docs
  • Build / CI

Evidence

Before

Test step log on main: the agent's project cwd is absent from allowWrite, so both the reported shape and the exact-list assertion fail

After

Test step log with the fix: the project cwd is writable through both layers, the hive paths are still there, and it is named once


Notes for review:

  • test/auto-mode-sandbox.test.cjs gains the reported shape — a project cwd that is not a parent of the hive, so nothing else in the list happens to cover it — and a dedup case for when cwd is also passed as an extra writable dir. The file's existing exact-list assertion is updated to include cwd, which is the behaviour change stated plainly rather than loosened into a contains.
  • Both new assertions fail on main.
  • sandboxWritableDirs() is untouched and still means "besides cwd". codex takes that same list through --add-dir, where -s workspace-write already grants the workspace, so its behaviour is unchanged.
  • npm run typecheck and the full npm run test:focused suite (836/836 on this branch) pass locally.

Discord: asr2805

Since 0.4.6 a spawned agent cannot write inside its own assigned project
cwd. Every Bash command that writes there — git commits and merges, build
output, rm, test artifacts — fails with "Operation not permitted", and the
only way through is turning the sandbox off for each command, which gives
up the whole layer to get work done. Read-only commands are unaffected,
which is why this reads as a broken agent rather than a sandbox.

The per-agent settings file declares `sandbox.filesystem.allowWrite` as the
paths BESIDES cwd — the agent's own hive folder, the hive root, the palace.
That was written on the evidence that bypass mode still wrote cwd itself,
verified live against claude 2.1.239. It no longer holds: once allowWrite
is present it is the whole answer, so the one directory the agent was
pointed at is the one directory it cannot write.

Name cwd in the list. It costs nothing where it was already implied, and
restores the agent's workspace where it is not. This does not widen the
sandbox — the agent could always read cwd, and everything outside these
paths stays denied. Both layers get it, as before: `allowWrite` governs
Bash children and `permissions.additionalDirectories` governs Edit/Write,
and with only one the agent deadlocks on its own inbox. The gate is
unchanged, so an agent spawned without a sandbox request stays exactly as
unsandboxed as it was.

test/auto-mode-sandbox.test.cjs covers the reported shape — a project cwd
that no other path in the list happens to cover — plus dedup when cwd is
also passed as an extra writable dir. Both fail on main.

Closes HarnessMD#449
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Spawned agents' Bash sandbox omits their project working directory — writes fail with EPERM (regression in v0.4.6)

1 participant