Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] sandbox silently fails despite `failIfUnavailable` set to `true` in VSCode (Cursor) terminal [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#46120•Fetched 2026-04-11 06:28:33
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Author
ozydingoozydingo
Participants
github-actions[bot]github-actions[bot]ozydingoozydingo
Timeline (top)
labeled ×6commented ×1

Error Message

Exit with an error at startup if sandbox.enabled is true but the sandbox cannot start

Error Messages/Logs

Code Example



---

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "denyWrite": ["./foo"]
    }
  }
}

---

claude -p 'Run `touch foo/file`'

---

claude -p 'Run `touch foo/file`'

---

sandbox-exec -p '(version 1)(allow default)' echo hello
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

The sandbox does not activate when Claude Code is run from Cursor's (VS Code fork) integrated terminal. sandbox.enabled: true and sandbox.failIfUnavailable: true are both set, but writes succeed to denied paths. No failure, no warning, exit code 0.

The same configuration correctly blocks writes when run from an external terminal (iTerm2). failIfUnavailable: true exists specifically so managed deployments can guarantee sandboxing is active. In this case it fails open with no indication that the security gate is missing.

What Should Happen?

Given "failIfUnavailable": true, Claude should:

Exit with an error at startup if sandbox.enabled is true but the sandbox cannot start

(from docs)

Error Messages/Logs

Steps to Reproduce

  1. Create settings.json
{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "denyWrite": ["./foo"]
    }
  }
}

  1. Run mkdir foo

  2. Open Cursor, open terminal panel. Run

claude -p 'Run `touch foo/file`'

Observe: claude succeeds, write succeeds.

  1. Control: open terminal / iterm. Run
claude -p 'Run `touch foo/file`'

Observe: write is blocked as expected

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.100

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Cursor

Additional Information

sandbox-exec works in both environments, confirmed with

sandbox-exec -p '(version 1)(allow default)' echo hello

extent analysis

TL;DR

The issue can be addressed by investigating the differences in environment variables or permissions between running Claude Code from Cursor's integrated terminal and an external terminal.

Guidance

  • Verify that the sandbox.enabled and sandbox.failIfUnavailable settings are being read correctly from the settings.json file when running from Cursor's integrated terminal.
  • Check the environment variables and permissions in both the integrated terminal and the external terminal to identify any differences that might affect the sandbox's ability to start.
  • Test running Claude Code with the --verbose flag (if available) or increasing the log level to gather more detailed output about the sandbox initialization process.
  • Consider comparing the output of sandbox-exec commands in both environments to see if there are any differences in how the sandbox is being executed.

Example

No specific code snippet is provided as the issue seems to be related to the environment or configuration rather than a code-level problem.

Notes

The fact that sandbox-exec works in both environments suggests that the issue might be specific to how Claude Code is interacting with the sandbox when run from Cursor's integrated terminal. The problem does not seem to be related to the Claude Code version, as the user is using the latest version.

Recommendation

Apply workaround: Investigate and adjust environment variables or permissions in Cursor's integrated terminal to match those of the external terminal, as this might resolve the issue with the sandbox not activating as expected.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#container setup#orchestration issue#cache issue#memory leak

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING