[BUG] Claude Code crashes with "exited with code 1" on multi-user macOS due to shared /tmp/claude-settings-<hash>.json

Resolved 💬 2 comments Opened Apr 22, 2026 by salsua Closed Jun 4, 2026

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

  1. On a Mac with two local user accounts (A and B), log in as user A.
  2. 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.

  1. Log out, log in as user B.
  2. Open the Claude Desktop app and start a new Claude Code session. It fails

instantly with "Claude Code process exited with code 1".

  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

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗