Cursor AI Agent Shell Tool Hangs on All Commands — macOS 16.4, ARM Mac
Environment:
New Apple Silicon Mac, macOS 16.4 (darwin 25.4.0)
Cursor: clean install from cursor.com (not migrated)
Files migrated from old x86 Mac via Migration Assistant
Symptom: The AI agent’s Shell tool hangs indefinitely on every command, including echo hello in /tmp. The Glob tool also hangs. The issue is system-wide — reproduced in a fresh test workspace with no project files.
What works:
Cursor’s built-in terminal (PTY-based) — ls, shell commands all work normally
AI agent Read tool (direct file reads with exact path) — works fine
Full Disk Access is granted to Cursor in Privacy & Security
What was ruled out:
Quarantine flags — removed from /Applications/Cursor.app and ~/.cursor, no change
Shell startup time — zsh -c ‘echo ok’ and zsh -i -c ‘echo ok’ both complete in ~46ms
Shell path — /bin/zsh exists and is correct
Security software — none installed
.cursorignore — none present
Symlink loops — none found
Directory permissions — normal
Hypothesis: The AI agent uses a pipe-based (non-PTY) subprocess that differs from the Cursor terminal’s PTY subprocess. Something in how that subprocess is spawned or how its I/O pipes are connected fails silently on this machine, causing every command to hang indefinitely rather than execute or error.
Additional notes:
Cursor’s built-in terminal (Ctrl+`) works perfectly in the same workspace
The AI agent Read tool (file reads with exact path) works perfectly
The issue persists across all workspaces and directories
Removing com.apple.quarantine from /Applications/Cursor.app had no effect
No security software (Little Snitch, antivirus, MDM, etc.) is installed
Steps to Reproduce
ask the agent to run any shell command — e.g. “run echo hello” or “list the files in this directory”
Expected Behavior
Expected: Shell command executes and returns output
Actual: Shell tool hangs indefinitely — no output, no error. Times out after however long the tool waits. Every shell command behaves this way, including echo “hello” in /tmp.
The root cause is that Cursor ships x86-only helper binaries (cursor-retrieval, cursor-agent-exec) that silently hang instead of failing with a clear error when Rosetta is not installed. They should either ship universal binaries or detect the missing Rosetta and show a prompt.
Thanks for following up here. I’m not aware of any intentional dependency on Rosetta. The macOS build ships as a Universal (fat) binary, and the agent’s native helpers are meant to run natively on Apple Silicon. But I’d bet this is connected to:
If Migration Assistant carried over an x86-only Cursor.app (or x86 helper binaries inside it) from your old Mac, that would explain it. The agent’s Shell/Glob tools spawn native helper binaries from inside the app bundle, and an Intel-only binary on Apple Silicon with no Rosetta won’t launch, whereas the built-in terminal and the Read tool don’t go through those helpers, which lines up exactly with what you’re seeing.
Worth a quick check. Can you run these and paste the output?
If any of those report x86_64 only (instead of arm64 / x86_64 arm64), that’s the culprit.
In any case, reinstalling Cursor from Cursor · Download should fix it. You can even download the ARM64 version instead of the Universal one, just to be sure!
I did multiple clean installs where I deleted installed cursor and downloaded and installed the macos version. The agent reports: The root cause is that Cursor ships x86-only helper binaries (cursor-retrieval, cursor-agent-exec) that silently hang instead of failing with a clear error when Rosetta is not installed.
Here is the output you requested, you can see the x86 binaries are part of the package:
elliotgarbus@Mac ~ % file “/Applications/Cursor.app/Contents/MacOS/Cursor”
lipo -archs “/Applications/Cursor.app/Contents/Resources/app/resources/helpers/cursorsandbox”