[BUG] Multi-user macOS: Claude Code exits with code 1 when /private/tmp/claude-settings-<hash>.json is owned by a different UID
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?
The Claude Code child process exits with code 1 on macOS systems with multiple user accounts, because the app writes to /private/tmp/claude-settings-<hash>.json using a filename that is not keyed to the user's UID. The first user to run Claude Code creates this file owned by their UID with mode -rw-r--r--. When a second macOS user subsequently runs Claude Code, their child process fails on this file and exits with code 1, with no user-facing error message. Only a system reboot, or manually removing the file, clears the state.
What Should Happen?
Claude Code should either (a) include the UID in the settings filename (for example, /private/tmp/claude-<UID>/settings-<hash>.json, matching the pattern already used for the /private/tmp/claude-<UID>/ directory), or (b) use $TMPDIR, which macOS provides as a per-user path. Additionally, when the child process can't read or write expected state files, it should surface a clear error message instead of silently exiting with code 1.
Error Messages/Logs
[CCD] [replaceRemoteMcpServers] Calling SDK with 7 total servers [Claude in Chrome, mcp-registry, computer-use, Claude Preview, ccd_session, ccd_directory, scheduled-tasks]
[error] Session local_... query error: Claude Code process exited with code 1
stack: 'Error: Claude Code process exited with code 1
at sIr.getProcessExitError (.../index.js:390:8041)
at ChildProcess.i (.../index.js:390:11086)
at Object.onceWrapper (node:events:623:26)
at ChildProcess.emit (node:events:520:35)
at ChildProcess._handle.onexit (node:internal/child_process:294:12)'
[CCD CycleHealth] unhealthy cycle (0s, hadFirstResponse=false, reason=no_response)
Sentry event IDs:
b0a4cd30e958483890ba65596aefbdd5
7c7ac98e103448b6984d6cc1f0dc59bb
f0b561cb0a41497eaccd7501822fbf49
db751a5b7e474b94a1c17b780ecc7f3a
17506ad8f5164bbc86840281ac1270c4
1a03d131560d4028b411bc9696be1ca3
Steps to Reproduce
- macOS machine with two user accounts (User A, UID 502; User B, UID 503). Both signed into Claude Desktop on the same Anthropic account.
- User A opens Claude Desktop and starts a Claude Code session. This succeeds and creates:
/private/tmp/claude-settings-<hash>.json(owned by UID 502, mode-rw-r--r--)/private/tmp/claude-502/(owned by UID 502, contains working-directory state)
- User A fully quits Claude Desktop via
Cmd+Q. Verified viasudo ps auxandsudo launchctl listthat no Claude processes or launchd jobs remain.
- Switch to User B. Open Claude Desktop and start a Claude Code session.
- Result: child process exits with code 1 immediately. No error shown to user.
Confirmed workaround (no reboot needed): sudo rm -rf /private/tmp/claude-*, then retry. User B's Claude Code session then works and creates its own /private/tmp/claude-503/.
Verified file ownership at the moment of reproduction:
$ ls -la /private/tmp/claude-*
-rw-r--r-- 1 userA wheel 2 Apr 24 15:23 /private/tmp/claude-settings-44136fa355b3678a.json
/private/tmp/claude-502:
drwxr-xr-x 3 userA wheel 96 Apr 24 15:24 -Users-userA--myProject
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
Claude 1.3883.0 (93ff6c) 2026-04-21T17:24:01.000Z (bundled Claude Code: 2.1.111)
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Terminal.app (macOS)
Additional Information
Extensively debugged before filing. Ruled out: skills plugin, MCP connectors (user-facing and internal), working directory, session state, keychain, auth, folder privacy permissions, and two-user process contention. All ruled out via sudo ps aux, sudo lsof, sudo launchctl list, and full resets of ~/Library/Application Support/Claude/ subdirectories. The /private/tmp/claude-settings-*.json ownership collision is the sole confirmed cause, and removal of that file is the sole required fix to restore function.
Full debugging session logs available on request.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗