[BUG] Claude Code crashes with "exited with code 1" on multi-user macOS due to shared /tmp/claude-settings-<hash>.json
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Starting a Claude Code session in the Claude Desktop app fails instantly. The Desktop app shows "Claude Code process exited with code 1" and the session never produces a response. This happens on macOS machines with more than one local user account: one user can use Claude Code fine, but any other user on the same Mac gets the crash on every session start.
What Should Happen?
Each user on a multi-user Mac should be able to start a Claude Code session independently, regardless of which user previously ran the app.
Error Messages/Logs
From ~/Library/Logs/Claude/main.log:
[error] Session local_... query error: Claude Code process exited with code 1
at sIr.getProcessExitError (/Applications/Claude.app/Contents/Resources/ap
p.asar/.vite/build/index.js:390:8041)
at ChildProcess._handle.onexit (node:internal/child_process:294:12)
main.log captures only the exit code, not the child's stderr. I wrapped the
claude binary with a shim that captured stderr. The real error is:
Error processing settings: EACCES: permission denied, open
'/tmp/claude-settings-44136fa355b3678a.json'
The file 44136fa355b3678a is the SHA-256 prefix of {} (empty settings). That
path was already owned by the other user on the machine (mode 644, sticky bit
on /tmp blocks overwrite by anyone else).
Steps to Reproduce
- On a Mac with two local user accounts (A and B), log in as user A.
- Open the Claude Desktop app and start a new Claude Code session in any
directory. Let it succeed — this creates /tmp/claude-settings-<hash>.json
owned by A.
- Log out, log in as user B.
- Open the Claude Desktop app and start a new Claude Code session. It fails
instantly with "Claude Code process exited with code 1".
- Confirm with: ls -la /tmp/claude-settings-* — the file is owned by A, mode
644, and user B can't overwrite because /tmp has the sticky bit.
Workaround: sudo rm /tmp/claude-settings-44136fa355b3678a.json (or sudo chmod
666 on it).
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.111 (Claude Code)
Platform
Other
Operating System
macOS
Terminal/Shell
Other
Additional Information
- The settings blob is hashed for the filename, so any two users whose
settings serialize identically (e.g., both {}) will collide on the same path
in /tmp. Empty settings is the common case.
- The claude binary already receives TMPDIR=/var/folders/.../T/ in its env,
which is per-user on macOS. Writing to $TMPDIR (or ~/Library/Application
Support/Claude/) instead of hard-coded /tmp would eliminate the collision
entirely.
- Separately: the Desktop app should capture the child process's stderr into
main.log (or surface it in the UI). Right now only the exit code is logged,
which makes this bug un-diagnosable without patching the binary. I only found
the root cause by replacing claude.app/Contents/MacOS/claude with a bash shim
that tee'd stderr to a file.
- Same Mac evidence: /tmp also contains claude-501/ and claude-503/
directories (per-UID), so the app already uses per-user paths for some things
— just not for this settings file. The inconsistency is likely the source of
the regression.
This happened was using the Desktop App, not the API or Terminal
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗