[BUG] Desktop app crashes on multi-user Mac: /tmp/claude-settings-*.json ownership collision
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 Desktop app (macOS) passes --settings {} to the bundled CLI binary. The CLI hashes this to a deterministic temp filename /tmp/claude-settings-44136fa355b3678a.json and writes the settings there.
On a Mac with multiple user accounts, the first user to open Claude Desktop creates this file with their ownership. When a second user opens Claude Desktop, the CLI crashes immediately with:
Error processing settings: EACCES: permission denied, open '/tmp/claude-settings-44136fa355b3678a.json'
The process exits with code 1 before producing any output. The desktop app shows "Claude Code process exited with code 1" with no further detail - the CLI's stderr is not captured in any log file, making this very hard to diagnose.
Key details:
- The filename is a deterministic hash of
{}(the settings content), so every user collides on the same file - The CLI works fine standalone (without
--settingsflag) - Only "local sessions" are affected; VM-based sessions work fine because they run inside an isolated VM
- ALL operations fail: queries, MCP server sync, model switching, context usage checks
- The desktop retries
replaceRemoteMcpServersrepeatedly in the background, generating hundreds of error entries
What Should Happen?
The temp settings file should use a user-specific path. Options:
- Include the UID in the filename:
/tmp/claude-settings-{hash}-${UID}.json - Use
$TMPDIR(macOS sets this to a per-user dir like/var/folders/xx/.../T/):$TMPDIR/claude-settings-{hash}.json - Write to
~/.claude/instead of/tmp/
Option 2 is the most correct for macOS - $TMPDIR is already per-user and private.
Error Messages/Logs
CLI stderr (only visible via binary wrapper):
Error processing settings: EACCES: permission denied, open '/tmp/claude-settings-44136fa355b3678a.json'
Desktop main.log (unhelpful):
Session local_xxx query error: Claude Code process exited with code 1
File ownership:
$ ls -la /tmp/claude-settings-44136fa355b3678a.json
-rw-r--r-- 1 otheruser wheel 2 Apr 23 17:24 /tmp/claude-settings-44136fa355b3678a.json
Steps to Reproduce
- Have two macOS user accounts (User A and User B) on the same Mac
- User A opens Claude Desktop app - creates
/tmp/claude-settings-44136fa355b3678a.jsonowned by User A - User B opens Claude Desktop app
- Every local session crashes immediately with exit code 1
Workaround
sudo rm /tmp/claude-settings-44136fa355b3678a.json
The file will be recreated with the current user's ownership. But it breaks again if the other user opens Claude Desktop first (e.g., after reboot).
Additional note
The desktop app does not log the CLI's stderr anywhere, so this error is invisible in all log files under ~/Library/Logs/Claude/. The only way to find the actual error was to replace the CLI binary with a wrapper script that captured stderr. Consider logging stderr to help debug future issues.
Claude Model
Opus
Is this a regression?
Yes - started after desktop app auto-updated (around Apr 21, 2026). The --settings flag appears to be new behavior from the updated desktop.
Last Working Version
Desktop version before 1.3883.0 (worked on Apr 20, 2026)
Claude Code Version
2.1.111 (bundled by desktop)
Platform
Claude Pro
Operating System
macOS (Darwin 24.6.0, arm64)
Terminal/Shell
Claude Desktop app (not terminal)
Additional Information
Related but different from #20139, #17034, #18163 which cover /tmp/claude/ directory collisions. This bug is about a separate code path: the --settings CLI flag writing deterministic temp files to /tmp/.
3 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This bug is not limited to local multi-user Macs — it also affects remote SSH sessions on Linux hosts where multiple users share
/tmp. Could this be reopened? The fix would resolve both scenarios.My environment: Single Linux host (Ubuntu 24.04, Plesk Obsidian) with multiple vhost users, each used as a separate SSH target from one Mac running Claude Desktop. All vhost users share
/tmp(Plesk SSH is not chrooted by default).Same deterministic filename collision, exact same EACCES error:
User
tipcp_devopened a Claude Code session on Apr 26 and wrote the file first. Every other vhost user has been hitting EACCES on session start ever since. Confirmed by the sameError processing settings: EACCESline in~/Library/Logs/Claude/main.log:Why this scenario matters: multi-tenant Plesk/cPanel hosts are common for users running Claude Code against multiple client environments on a single VPS. Mac multi-user is rare; shared-
/tmpLinux hosts are not.Suggested fix is the same (option 2 from the original report —
$TMPDIRper-user, or include UID in filename) and would resolve both the macOS and Linux/SSH variants in one change.Workaround on shared Linux hosts (until fixed): periodically delete the stale file as the user who owns it, e.g.
ssh tipcp_dev 'rm -f /tmp/claude-settings-*.json'between switching vhost sessions. Painful at scale.Also seconding the original report's note that the desktop app does not surface the CLI's stderr in any log — the only reason this was diagnosable in my case was tailing
main.logand noticing the[RemoteProcess]stderr:warning line.Claude Desktop version: 1.5354.0
Claude Code (bundled): 2.1.121
Desktop OS: macOS 15.5
Remote OS: Ubuntu 24.04 LTS
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.