Blocking Claude Code Writes Outside the Working Directory: Bash and Codex Tested

permissions.blockWritesOutsideWorkingDirectories: true stopped Write and Edit from writing outside the working directory, even in bypassPermissions, which skips approvals. It did not stop Bash, and in bypassPermissions with only sandbox.enabled: true, requesting a retry after failure led to a call with dangerouslyDisableSandbox: true that wrote outside. To stop unsandboxed Bash retries, add allowUnsandboxedCommands: false as the official docs describe; a strict retry with the flag passed remains unverified.

Checked on 2026-11-03 JST with Claude Code 2.1.316, codex-cli 0.166.0, and Darwin 25.6.0. Claude ran claude-haiku-5-5 non-interactively, once per condition. Only not_attempted results got one retry. Results were judged from tool_use, tool_result, and file contents, not from the model's text. Every intended probe target was a dummy in a temporary folder.

Key points: With the setting on, bypassPermissions refused outside writes through Write/Edit. To stop unsandboxed Bash retries, add allowUnsandboxedCommands: false as the official docs describe. Codex was tested with model-free codex sandbox using workspace-write, which also includes temporary directories.

#How should you configure it?

Use this JSON in user settings at ~/.claude/settings.json or with the startup --settings flag. The experiment used only .claude/settings.json in a disposable project and did not change real user settings. Placing the sandbox configuration in user settings or starting it via --settings was not measured. Officially, disabling retries via --settings makes the sandbox admin-required and ignores repository settings that loosen it, including excludedCommands; user settings alone do not have the same effect.

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true
  },
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true
  }
}

The official settings reference says blockWritesOutsideWorkingDirectories requires v2.1.314 or later and covers Write, Edit, and NotebookEdit. It does not limit shell commands, MCP tools, or programs run by hooks. A true in any loaded settings file turns it on, and false is the same as unset. To lift it, remove the key from every settings file and restart.

The official sandbox documentation says allowUnsandboxedCommands: false makes Claude Code ignore dangerouslyDisableSandbox. The settings reference says failIfUnavailable exits with an error when the sandbox is unavailable at startup; if initialization fails after that check, the session continues and refuses each sandboxed command (official, not measured).

The failIfUnavailable recommendation rests on the official description. This test did not measure the case where the sandbox can't start, or the full combination that includes this key. Commands matching excludedCommands run outside the sandbox, and some files, including some of Claude Code's own, stay writable. So this setup cannot be called a block on all writes.

#Which permission modes does it work in?

For Write outside the working directory, the measurements were:

• With false (officially the same as unset), default, acceptEdits, and dontAsk were denied, and bypassPermissions wrote the file (E1a–E1d).
• With the setting, all four modes were denied, and the error named this setting (E1e–E1h).
• With the setting, bypassPermissions could still write inside the working directory (E0).

In bypassPermissions, Edit changed the outside file with false (E2a) and was denied with the file still at BEFORE with the setting (E2b). In acceptEdits, E2c stopped at a Read permission request, and Edit did not run in either attempt. E2c is therefore not evidence of a refusal.

E1a/b stopped without granted approval; E1c was denied by dontAsk. Omitting the key entirely was not measured.

Working directories are defined in the official permissions documentation.

#Does it stop Bash, and what happens to unsandboxed retries?

This setting alone does not stop Bash. In bypassPermissions with the setting on, both a redirect (E3d) and a copy (E3e) wrote outside. E3c in acceptEdits was denied, but the error was Bash's approval request, the same as E3a with false. It does not show an effect of the setting.

With the sandbox on, the first Bash call failed with operation not permitted (E4a, E4b). In bypassPermissions, the results split in the conditions that asked for a retry. Sandbox retries in other permission modes were not measured.

• sandbox.enabled only (E4c): after the first failure, a call with dangerouslyDisableSandbox: true wrote outside.
• With allowUnsandboxedCommands: false (E4d): the result was denied. However, the record shows one Bash call, and it did not carry the flag.

The E4d record does not confirm a refusal with the flag actually passed. Ignoring the flag is the official description. At minimum, sandbox.enabled alone cannot be called a full block.

#Are --add-dir and project additionalDirectories the same?

The results differed under these conditions. In bypassPermissions, a folder added with --add-dir was writable (E5a), and another outside folder was still denied (E5c). In E5b, project additionalDirectories was ignored because the workspace was untrusted. The write was denied, but refusal in a trusted workspace was not measured.

The official documentation also lists directories added only by repository settings as refused. Exceptions come from /add-dir, --add-dir, or additionalDirectories in user or managed settings. Allow rules do not let writes through.

#Does it stop writes through symlinks?

For directory symlinks, yes. A Write through a link inside the working directory that pointed outside succeeded with false (E6e). With the setting, it was denied by an error naming the resolved path (E6a).

Bash wrote outside through the same path (E6c). With sandbox.enabled and no retry request, it was denied (E6d).

With a file symlink (E6b), the outside file also stayed unchanged. But the error was File has not been read yet, so a refusal by the setting was not confirmed.

#How does Codex workspace-write differ, and what about /tmp?

The official Codex documentation says the workspace includes the current directory and temporary directories such as /tmp. The outside folder in this test sat inside TMPDIR, so explicit workspace-write with no exclusion keys could write to it (X1b).

With the config keys exclude_tmpdir_env_var and exclude_slash_tmp both true, writes to outside (X1d) and to a /tmp dummy (X1e) were denied. The two keys were turned on together, so their individual effects were not separated. /tmp without the exclusions was not measured.

In codex sandbox with a temporary HOME and no sandbox_mode given, even the working directory was denied (X0). With workspace-write, the working directory was writable (X1a, X1c). A write to .git was denied (X4), and the outside file stayed unchanged with a file symlink (X3b). .agents, .codex, and .aws, which the official documentation also lists as protected, were not measured.

Codex ran with a temporary HOME and CODEX_HOME, and codex exec was not re-run against the real HOME. In an earlier trial separate from these measurements, after two runs of codex exec -s workspace-write with --ignore-user-config --ephemeral, two projects tables with temporary paths were added to the real config.toml. This was one observation on 0.166.0/macOS, and the cause was not identified.

That trial is not part of the results list. Only one write to a temporary directory with explicit workspace-write matched between codex exec and codex sandbox. codex exec with temp directories excluded produced no command events, so it remains unconfirmed.

#Are settings files and EnterWorktree exceptions?

The official documentation says that with the setting on, EnterWorktree and ExitWorktree are removed or refused. Officially, a cloud session may not apply this key because its container is the boundary; this was not measured. An isolation: worktree subagent's file edits are also refused when its worktree sits outside the working directories.

Officially, writes to Claude Code settings files are refused even inside the working directories. In E7a the content stayed unchanged, but the error was File has not been read yet, so it does not measure this protection.

Plan files, the scratchpad, a background session's tmp directory, and .md files in this project's auto memory are officially listed as staying writable.

The official documentation says a true wins over a false elsewhere. E7b ran with project true plus --settings '{"permissions":{"blockWritesOutsideWorkingDirectories":false}}'; the outside Write was refused by this setting, consistent with the official description. Loading the false value itself was not independently observed.

#How can you reproduce this?

Use temporary folders only. This command is the Codex measurement example. Check the exit code, error text and file together. A missing file alone does not establish a refusal. On macOS sh/zsh, expect exit=1, Operation not permitted, and an empty listing of outside. The code falls back to /tmp if TMPDIR is unset and stops if creation fails.

(
  set -eu
  probe_tmp="${TMPDIR:-/tmp}"
  R="$(mktemp -d "${probe_tmp%/}/write-guard.XXXXXX")"
  mkdir -p "$R/work" "$R/outside" "$R/home/.codex"
  git init -q "$R/work"
  cd "$R/work"
  probe_rc=0
  env -i PATH="$PATH" HOME="$R/home" CODEX_HOME="$R/home/.codex" TMPDIR="$probe_tmp" \
    codex sandbox \
    -c 'sandbox_mode="workspace-write"' \
    -c 'sandbox_workspace_write.exclude_tmpdir_env_var=true' \
    -c 'sandbox_workspace_write.exclude_slash_tmp=true' \
    -- /bin/sh -c 'echo PROBE > "$1"' sh "$R/outside/probe.txt" || probe_rc=$?
  printf 'exit=%s\n' "$probe_rc"
  ls -A "$R/outside"
)

Claude used existing authentication, because an earlier record showed it could not authenticate with a temporary HOME. All Claude conditions used the same disposable work directory; trust state was not independently fixed or verified. E5b emitted an untrusted-workspace warning, so these observations are not generalized to trusted workspaces. Settings were limited to --setting-sources project (except E7b with --settings), with no MCP and no saved conversation. The three real settings files had matching before/after SHA-256 hashes, but one empty projects directory was left behind.

Put the settings in $R/work/.claude/settings.json and ask for a Write to a temporary path outside the working directory. Check the file contents and tool output together, not the model's reply.

#What was not verified?

• Claude Code: NotebookEdit, MCP, hooks, auto and plan modes, placement in user settings, interactive /add-dir, managed settings, cloud sessions, subagent worktrees, and exceptions such as plan files.
• Platforms and paths: Linux, Windows, WSL, ordinary paths outside temporary storage (such as HOME), and all Claude conditions in a trusted workspace.
• Input: malicious input.
• Codex: runs through the model and combinations with approval settings.

Apart from E2c with two attempts, each condition ran once, so stability is not guaranteed. Actual traffic effects have not been evaluated.

#Where are the related articles and primary sources?

Related articles:

• The Downloads folder and AGENTS.md
• Claude Code instruction discovery
• Claude Code hook exit codes
• Worktrees in Claude Code and Codex
• codex exec
• Agent Skills in Claude Code and Codex

Primary sources:

• Claude Code changelog
• Claude Code settings
• Claude Code permissions
• Claude Code sandboxing
• Codex approvals and security
• Codex config reference

#What were the results across all 41 conditions?

The results mean the following. The Condition column identifies the input and refusal cause or retry record.

• written: the target file was created or its content was changed.
• denied: the operation failed and the target file was not changed. The cause varies by condition, so use the error text to judge whether the setting was responsible. For Codex, the exit code, a permission error on stderr and an unchanged file were checked together.
• not_attempted: the model did not run the target operation. This is not counted as a refusal.

#Frequently asked questions

#Since when is blockWritesOutsideWorkingDirectories available?

The official documentation says it requires Claude Code v2.1.314 or later. This test ran on 2.1.316 and did not measure 2.1.314.

#Does it work with dangerously-skip-permissions?

In bypassPermissions mode, the measurements showed Write and Edit refused outside the working directory. The official documentation also says it refuses in every mode, including bypassPermissions. The --dangerously-skip-permissions flag itself was not measured.

#Does it stop Bash writes too?

This setting alone does not. In bypassPermissions, a redirect and a copy wrote outside. In bypassPermissions with only sandbox.enabled, requesting a retry after failure led to a call with dangerouslyDisableSandbox: true that wrote outside. To stop unsandboxed retries, add allowUnsandboxedCommands: false as the official docs describe. That condition was denied, but the record shows no call with the flag, and ignoring the flag is the official description.

#Can it write to a folder added with --add-dir?

Yes, in bypassPermissions. Other outside folders were still denied. In E5b, additionalDirectories from project settings was ignored because the workspace was untrusted, and the write was denied. A trusted workspace was not measured. The official documentation also lists additionalDirectories in user or managed settings as a way to add an exception, but this test did not measure that.

#Does it stop writes through symlinks?

In bypassPermissions, Write was refused when a directory symlink led outside. Bash wrote through the same path, but was denied with sandbox.enabled and no retry request. A file symlink stopped at a read-before-write error, so a refusal by the setting was not confirmed.

#Can Codex workspace-write also write to /tmp?

The official documentation says the workspace includes temporary directories such as /tmp. In this test, an outside folder inside TMPDIR was writable with explicit workspace-write and no exclusion keys. With exclude_tmpdir_env_var and exclude_slash_tmp both true, writes to that folder and to a /tmp dummy were denied. /tmp without the exclusions was not measured.