[BUG]

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?

Bug Report: Claude Code Desktop — Shared /tmp Settings File Blocks Multi-User SSH Connections on Linux

Product: Claude Code Desktop (Windows client) + ccd-cli (Linux remote runtime)
ccd-cli version: 2.1.111
Server OS: Oracle Linux (RHEL-family), kernel 5.x
Impact: Severity: High for shared-server deployments. Second user to reconnect is blocked with "Connection failed / Code 1" until manual filesystem intervention.

---

Summary

When Claude Code Desktop establishes a remote session via SSH to a Linux host shared by multiple user accounts, ccd-cli writes a merged-settings cache to a path in /tmp whose filename is derived from a deterministic hash that does not include the UID or username. The file is created with O_CREAT | O_WRONLY and default umask, resulting in permissions -rw-r--r-- (writable only by the creating user). On any filesystem with the sticky bit set on /tmp (the RHEL/Fedora/Oracle Linux default), the second user cannot delete or rewrite the file, causing ccd-cli to exit with code 1 and Claude Code Desktop to display "Connection failed."

Environment

• Host: Single Linux VM with two distinct Unix user accounts (argent, argent2) that occasionally connect simultaneously via separate Claude Code Desktop instances on different Windows workstations.
• Client: Claude Code Desktop on Windows 11. Each user connects via SSH with their own key-based auth to their own account on the same host.
• Binary path: /home/<user>/.claude/remote/ccd-cli/2.1.111 (identical binary, 235842176 bytes, in each user's home).

Reproduction

1. User A (argent2) connects via Claude Code Desktop. ccd-cli launches and writes /tmp/claude-settings-44136fa355b3678a.json (2 bytes, -rw-r--r-- argent2 argent2).
2. User A works normally.
3. User B (argent) connects via Claude Code Desktop.
4. ccd-cli on behalf of User B attempts to open the same path with O_WRONLY | O_CREAT, receives EACCES, writes to stderr:

``
Error processing settings: EACCES: permission denied, open '/tmp/claude-settings-44136fa355b3678a.json'
``
and exits with code 1.

1. Claude Code Desktop displays "Connection failed" with no surfaced error detail.

Confirmed via strace

User B invocation using Desktop-equivalent flags:

$ strace -f -e trace=openat /home/argent/.local/bin/claude --print \
    --setting-sources=user,project,local --settings '{}' "hello"

openat(AT_FDCWD, "/tmp/claude-settings-44136fa355b3678a.json",
       O_WRONLY|O_CREAT, 0666) = -1 EACCES (Permission denied)

Bidirectionally reproducible: After User B becomes the file owner, User A hits the identical EACCES. Confirmed by running the same strace command from argent2 while the file was -rw-r--r-- argent argent.

Root Cause Hypothesis

• The filename hash 44136fa355b3678a appears deterministic from inputs that do not vary by user (possibly the binary version, install ID, or host fingerprint). Both users on the same host compute the same hash and target the same path.
• The file is opened with O_WRONLY | O_CREAT and umask-trimmed 0644 permissions — write access is restricted to the creating UID.
• /tmp on RHEL-family distributions has the sticky bit set (drwxrwxrwt), so only the owner or root can unlink the file.
• When the second user's ccd-cli hits O_CREAT on an existing file, the kernel short-circuits to a standard open, which then fails because the process UID doesn't match the file's owner UID for write access.

Isolating the Trigger

The minimal flags that trigger the collision:

• --setting-sources=user,project,local combined with --settings '{}'

A plain --print "hello" invocation does not touch /tmp/claude-settings-*.json. Verified via strace — zero matches on the filename pattern.

Suggested Fixes (in order of simplicity)

1. Include UID or username in the filename: /tmp/claude-settings-<uid>-<hash>.json or /tmp/claude-settings-<hash>-<username>.json. One-line fix, fully backwards compatible.
2. Move the cache under $HOME: ~/.cache/claude/settings-<hash>.json. Per-user by construction, XDG Base Directory-compliant, survives /tmp cleanup on reboot.
3. Open with O_CREAT | O_EXCL and fall back: If the shared filename exists and is not writable, retry with a UID-scoped filename.

Workaround (current)

The affected user, or their colleague who owns the file, runs:

rm -f /tmp/claude-settings-44136fa355b3678a.json

after which the blocked user can reconnect successfully (and now owns the new file, reversing the block).

Business Impact

In our deployment, this bug means only one team member can use Claude Code Desktop at a time, despite each having a distinct user account, distinct SSH keys, and separate home directories. The issue is invisible from the Claude Code Desktop UI — there is no error message surfaced beyond "Connection failed" and "Code 1" — so root-causing requires SSH access, strace, and working knowledge of Linux filesystem semantics. Diagnosis took approximately 2 hours of troubleshooting with prior Claude assistance.

Contact

Happy to provide additional logs, strace output, or test fixes.

What Should Happen?

Bug Report: Claude Code Desktop — Shared /tmp Settings File Blocks Multi-User SSH Connections on Linux

Product: Claude Code Desktop (Windows client) + ccd-cli (Linux remote runtime)
ccd-cli version: 2.1.111
Server OS: Oracle Linux (RHEL-family), kernel 5.x
Impact: Severity: High for shared-server deployments. Second user to reconnect is blocked with "Connection failed / Code 1" until manual filesystem intervention.

---

Summary

When Claude Code Desktop establishes a remote session via SSH to a Linux host shared by multiple user accounts, ccd-cli writes a merged-settings cache to a path in /tmp whose filename is derived from a deterministic hash that does not include the UID or username. The file is created with O_CREAT | O_WRONLY and default umask, resulting in permissions -rw-r--r-- (writable only by the creating user). On any filesystem with the sticky bit set on /tmp (the RHEL/Fedora/Oracle Linux default), the second user cannot delete or rewrite the file, causing ccd-cli to exit with code 1 and Claude Code Desktop to display "Connection failed."

Environment

• Host: Single Linux VM with two distinct Unix user accounts (argent, argent2) that occasionally connect simultaneously via separate Claude Code Desktop instances on different Windows workstations.
• Client: Claude Code Desktop on Windows 11. Each user connects via SSH with their own key-based auth to their own account on the same host.
• Binary path: /home/<user>/.claude/remote/ccd-cli/2.1.111 (identical binary, 235842176 bytes, in each user's home).

Reproduction

1. User A (argent2) connects via Claude Code Desktop. ccd-cli launches and writes /tmp/claude-settings-44136fa355b3678a.json (2 bytes, -rw-r--r-- argent2 argent2).
2. User A works normally.
3. User B (argent) connects via Claude Code Desktop.
4. ccd-cli on behalf of User B attempts to open the same path with O_WRONLY | O_CREAT, receives EACCES, writes to stderr:

``
Error processing settings: EACCES: permission denied, open '/tmp/claude-settings-44136fa355b3678a.json'
``
and exits with code 1.

1. Claude Code Desktop displays "Connection failed" with no surfaced error detail.

Confirmed via strace

User B invocation using Desktop-equivalent flags:

$ strace -f -e trace=openat /home/argent/.local/bin/claude --print \
    --setting-sources=user,project,local --settings '{}' "hello"

openat(AT_FDCWD, "/tmp/claude-settings-44136fa355b3678a.json",
       O_WRONLY|O_CREAT, 0666) = -1 EACCES (Permission denied)

Bidirectionally reproducible: After User B becomes the file owner, User A hits the identical EACCES. Confirmed by running the same strace command from argent2 while the file was -rw-r--r-- argent argent.

Root Cause Hypothesis

• The filename hash 44136fa355b3678a appears deterministic from inputs that do not vary by user (possibly the binary version, install ID, or host fingerprint). Both users on the same host compute the same hash and target the same path.
• The file is opened with O_WRONLY | O_CREAT and umask-trimmed 0644 permissions — write access is restricted to the creating UID.
• /tmp on RHEL-family distributions has the sticky bit set (drwxrwxrwt), so only the owner or root can unlink the file.
• When the second user's ccd-cli hits O_CREAT on an existing file, the kernel short-circuits to a standard open, which then fails because the process UID doesn't match the file's owner UID for write access.

Isolating the Trigger

The minimal flags that trigger the collision:

• --setting-sources=user,project,local combined with --settings '{}'

A plain --print "hello" invocation does not touch /tmp/claude-settings-*.json. Verified via strace — zero matches on the filename pattern.

Suggested Fixes (in order of simplicity)

1. Include UID or username in the filename: /tmp/claude-settings-<uid>-<hash>.json or /tmp/claude-settings-<hash>-<username>.json. One-line fix, fully backwards compatible.
2. Move the cache under $HOME: ~/.cache/claude/settings-<hash>.json. Per-user by construction, XDG Base Directory-compliant, survives /tmp cleanup on reboot.
3. Open with O_CREAT | O_EXCL and fall back: If the shared filename exists and is not writable, retry with a UID-scoped filename.

Workaround (current)

The affected user, or their colleague who owns the file, runs:

rm -f /tmp/claude-settings-44136fa355b3678a.json

after which the blocked user can reconnect successfully (and now owns the new file, reversing the block).

Business Impact

In our deployment, this bug means only one team member can use Claude Code Desktop at a time, despite each having a distinct user account, distinct SSH keys, and separate home directories. The issue is invisible from the Claude Code Desktop UI — there is no error message surfaced beyond "Connection failed" and "Code 1" — so root-causing requires SSH access, strace, and working knowledge of Linux filesystem semantics. Diagnosis took approximately 2 hours of troubleshooting with prior Claude assistance.

Contact

Happy to provide additional logs, strace output, or test fixes.

Error Messages/Logs

Steps to Reproduce

Bug Report: Claude Code Desktop — Shared /tmp Settings File Blocks Multi-User SSH Connections on Linux

Product: Claude Code Desktop (Windows client) + ccd-cli (Linux remote runtime)
ccd-cli version: 2.1.111
Server OS: Oracle Linux (RHEL-family), kernel 5.x
Impact: Severity: High for shared-server deployments. Second user to reconnect is blocked with "Connection failed / Code 1" until manual filesystem intervention.

---

Summary

When Claude Code Desktop establishes a remote session via SSH to a Linux host shared by multiple user accounts, ccd-cli writes a merged-settings cache to a path in /tmp whose filename is derived from a deterministic hash that does not include the UID or username. The file is created with O_CREAT | O_WRONLY and default umask, resulting in permissions -rw-r--r-- (writable only by the creating user). On any filesystem with the sticky bit set on /tmp (the RHEL/Fedora/Oracle Linux default), the second user cannot delete or rewrite the file, causing ccd-cli to exit with code 1 and Claude Code Desktop to display "Connection failed."

Environment

• Host: Single Linux VM with two distinct Unix user accounts (argent, argent2) that occasionally connect simultaneously via separate Claude Code Desktop instances on different Windows workstations.
• Client: Claude Code Desktop on Windows 11. Each user connects via SSH with their own key-based auth to their own account on the same host.
• Binary path: /home/<user>/.claude/remote/ccd-cli/2.1.111 (identical binary, 235842176 bytes, in each user's home).

Reproduction

1. User A (argent2) connects via Claude Code Desktop. ccd-cli launches and writes /tmp/claude-settings-44136fa355b3678a.json (2 bytes, -rw-r--r-- argent2 argent2).
2. User A works normally.
3. User B (argent) connects via Claude Code Desktop.
4. ccd-cli on behalf of User B attempts to open the same path with O_WRONLY | O_CREAT, receives EACCES, writes to stderr:

``
Error processing settings: EACCES: permission denied, open '/tmp/claude-settings-44136fa355b3678a.json'
``
and exits with code 1.

1. Claude Code Desktop displays "Connection failed" with no surfaced error detail.

Confirmed via strace

User B invocation using Desktop-equivalent flags:

$ strace -f -e trace=openat /home/argent/.local/bin/claude --print \
    --setting-sources=user,project,local --settings '{}' "hello"

openat(AT_FDCWD, "/tmp/claude-settings-44136fa355b3678a.json",
       O_WRONLY|O_CREAT, 0666) = -1 EACCES (Permission denied)

Bidirectionally reproducible: After User B becomes the file owner, User A hits the identical EACCES. Confirmed by running the same strace command from argent2 while the file was -rw-r--r-- argent argent.

Root Cause Hypothesis

• The filename hash 44136fa355b3678a appears deterministic from inputs that do not vary by user (possibly the binary version, install ID, or host fingerprint). Both users on the same host compute the same hash and target the same path.
• The file is opened with O_WRONLY | O_CREAT and umask-trimmed 0644 permissions — write access is restricted to the creating UID.
• /tmp on RHEL-family distributions has the sticky bit set (drwxrwxrwt), so only the owner or root can unlink the file.
• When the second user's ccd-cli hits O_CREAT on an existing file, the kernel short-circuits to a standard open, which then fails because the process UID doesn't match the file's owner UID for write access.

Isolating the Trigger

The minimal flags that trigger the collision:

• --setting-sources=user,project,local combined with --settings '{}'

A plain --print "hello" invocation does not touch /tmp/claude-settings-*.json. Verified via strace — zero matches on the filename pattern.

Suggested Fixes (in order of simplicity)

1. Include UID or username in the filename: /tmp/claude-settings-<uid>-<hash>.json or /tmp/claude-settings-<hash>-<username>.json. One-line fix, fully backwards compatible.
2. Move the cache under $HOME: ~/.cache/claude/settings-<hash>.json. Per-user by construction, XDG Base Directory-compliant, survives /tmp cleanup on reboot.
3. Open with O_CREAT | O_EXCL and fall back: If the shared filename exists and is not writable, retry with a UID-scoped filename.

Workaround (current)

The affected user, or their colleague who owns the file, runs:

rm -f /tmp/claude-settings-44136fa355b3678a.json

after which the blocked user can reconnect successfully (and now owns the new file, reversing the block).

Business Impact

In our deployment, this bug means only one team member can use Claude Code Desktop at a time, despite each having a distinct user account, distinct SSH keys, and separate home directories. The issue is invisible from the Claude Code Desktop UI — there is no error message surfaced beyond "Connection failed" and "Code 1" — so root-causing requires SSH access, strace, and working knowledge of Linux filesystem semantics. Diagnosis took approximately 2 hours of troubleshooting with prior Claude assistance.

Contact

Happy to provide additional logs, strace output, or test fixes.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Version 1.3883.0 (93ff6c)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_