Sandbox fails to initialize for zsh on macOS 26 Tahoe (darwin25): zsh 5.9 reads unwhitelisted hw.* sysctls

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

On macOS 26 Tahoe (Darwin 25.x), every sandboxed command spawned through the user’s default shell (/bin/zsh) fails silently with exit code 1 and no
stdout/stderr. The OS-level sandbox-exec primitive is fine — it executes echo and other simple binaries inside a (deny default) profile without issue. The
failure is specifically that zsh 5.9 cannot initialize under a (deny default) Seatbelt profile on darwin25 because it reads several hw.* sysctls at startup that
the profile does not whitelist (hw.targettype, hw.osenvironment, hw.features.allows_security_research, hw.jetsam_properties_product_type). Bash inside the same
profile runs normally.

This appears to be the same regression already reported in detail against Claude Code: anthropics/claude-code#49820

Steps to Reproduce

Bash works fine inside a deny-default Seatbelt profile:

sandbox-exec -p ‘(version 1)(deny default)(allow process-fork)(allow process-exec)(allow file-read*)’
/bin/bash -c ‘echo from-bash’

→ “from-bash”, exit 0

zsh dies silently before it can run the command:

sandbox-exec -p ‘(version 1)(deny default)(allow process-fork)(allow process-exec)(allow file-read*)’
/bin/zsh -c ‘echo from-zsh’

→ empty output, exit 1

In Cursor, with sandbox.mode: “enabled” in ~/.cursor/cli-config.json and $SHELL=/bin/zsh, every sandboxed agent command exhibits the same exit-1-no-output
behavior.

Expected Behavior

Sandboxed commands should run under the user’s default shell on Tahoe just as they do on Sequoia (darwin24), without requiring users to disable the sandbox,
switch shells, or fall back to the legacy terminal tool.

Operating System

MacOS

Version Information

• OS: macOS 26.5 (Build 25F71), Darwin kernel 25.5.0, arm64
• Shell: /bin/zsh (zsh 5.9, arm64-apple-darwin25.0)
• Cursor CLI: cursor-agent 2026.05.16-0338208
• Config: sandbox.mode: “enabled”, approvalMode: “allowlist” in ~/.cursor/cli-config.json

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

Thanks for the detailed report and the sandbox-exec repro commands. I confirmed that zsh 5.9 on macOS 26.5 Tahoe does need hw.* sysctl access to initialize, and your standalone sandbox-exec test is valid: a bare (deny default) policy with no sysctl-read rules kills zsh silently.

However, when I tested with the actual Cursor CLI sandbox (sandbox.mode: "enabled", $SHELL=/bin/zsh, macOS 26.5 Tahoe on M4 Pro), commands ran successfully under zsh. The Cursor sandbox includes a broader sysctl whitelist than the minimal policy in your repro, and that whitelist appears to cover what zsh 5.9 needs on darwin25.

This makes me think the failure you’re seeing in Cursor might involve a different sandbox denial beyond sysctls (or something specific to your zsh config/plugins). Could you run the CLI with sandbox debug logging so we can see exactly what’s being denied?

SBX_DEBUG=1 cursor agent --trust "run echo hello" 2>&1 | tee /tmp/sbx-debug.log

If that doesn’t produce debug output, also try checking the system log for sandbox denials right after a failed command:

log show --predicate 'eventMessage CONTAINS "deny" AND eventMessage CONTAINS "sysctl"' --last 5m

Share whatever output you get and we can pinpoint the exact denial.

To unblock yourself now:

  • Set "sandbox.mode": "off" in ~/.cursor/cli-config.json
7

Seems to be working now.. second time I have this issue and right after reaching out to support it somehow fixes itself lol.

Anyways thank you