Sandbox fails to initialize on macOS 26 (Tahoe), forces dangerouslyDisableSandbox per call

Summary

On macOS 26.4.1 (Tahoe) with Claude Code 2.1.126, every Bash subprocess fails with Sandbox failed to initialize regardless of sandbox.enabled/failIfUnavailable configuration. The OS sandbox-exec primitive itself is intact — minimal profiles work fine when invoked directly. The failure appears to be inside Claude Code's sandbox profile generation or invocation path on this OS version.

failIfUnavailable: false does not prevent the failure from surfacing; the user is forced to approve dangerouslyDisableSandbox: true on every Bash call to make progress.

Environment

• OS: macOS 26.4.1 (Tahoe), Build 25E253
• Kernel: Darwin 25.4.0 arm64 (Apple Silicon)
• Claude Code: 2.1.126
• claude doctor is not available; no built-in diagnostic subcommand to attach.

Reproducer

1. Open a Claude Code session in any project on macOS 26.4.x with sandbox.enabled: true.
2. The very first Bash tool call returns: Sandbox failed to initialize.
3. Retrying with dangerouslyDisableSandbox: true succeeds.
4. The same first-Bash failure happens on every cold session, every time.

Relevant settings (sanitized, illustrative subset of what's in use):

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": false,
    "excludedCommands": [
      "docker *",
      "watchman *",
      "git commit *",
      "git push *"
    ],
    "filesystem": {
      "allowWrite": [
        "~/.config/chezmoi/",
        "~/.cache/",
        "~/.npm/",
        "~/.cargo/registry/"
      ]
    },
    "network": {
      "allowLocalBinding": true,
      "allowedDomains": [
        "api.github.com",
        "github.com",
        "api.anthropic.com",
        "*.anthropic.com",
        "code.claude.com",
        "registry.npmjs.org",
        "pypi.org",
        "files.pythonhosted.org"
      ],
      "allowUnixSockets": [
        "~/.1password/agent.sock",
        "$SSH_AUTH_SOCK"
      ]
    }
  }
}

The behavior reproduces with much simpler configurations as well — even with only sandbox.enabled: true and no other keys set, the first Bash call fails to initialize on macOS 26.4.1.

Diagnostic findings

I verified the OS sandbox primitive is healthy:

• sandbox-exec -p '(version 1)(allow default)' /bin/echo hi → success
• sandbox-exec with (version 1)(deny default) plus explicit allows → also succeeds for matching ops

So the OS-level Seatbelt mechanism that Claude Code wraps is functional on macOS 26.4.1. The init failure is somewhere upstream of sandbox-exec invocation — possibly in profile generation, path resolution, or a code path that assumes a macOS ≤25.x convention.

failIfUnavailable: false does not actually warn-and-continue

Per the docs and the field name, failIfUnavailable: false should mean if the sandbox can't initialize, run the command unsandboxed and continue. Observed behavior is that the failure is surfaced as a hard tool error, not a warning, so the model has to override with dangerouslyDisableSandbox: true for every call.

Two possibilities, either of which would help:

1. The init-time path doesn't honor failIfUnavailable: false — it only catches runtime sandbox failures. If so, this is a bug independent of the macOS 26 issue: the flag should also catch init failures.
2. The flag is honored but a separate code path surfaces an error before the fallback runs.

Plan-mode interaction (workaround friction)

dangerouslyDisableSandbox: true per call works, but in plan mode it triggers a per-call approval prompt regardless of the static permission allowlist. Read-only ops like find, grep, ls all prompt. With cold-session sandbox failure as the new normal on macOS 26, the per-call approval defeats the purpose of the allowlist.

Workaround

Setting sandbox.enabled: false globally is the only reliable fix today, but it eliminates the sandbox entirely — undesirable for daily work where sandboxing genuinely helps.

Asks

1. Confirm/test on macOS 26.x. If reproducible, scope a fix in the sandbox profile/invocation path.
2. Honor failIfUnavailable: false at init time — currently it appears to only catch runtime failures.
3. Optional: consider a claude doctor subcommand or a --diagnose-sandbox flag that surfaces what specifically is failing (profile path, sandbox-exec exit code, etc.). This would help users distinguish OS-level vs Claude Code-level sandbox issues.