On Linux, an unmapped user namespace now refuses the daemon socket and suggests unshare -Ur.
What's wrong with this entry?
On Linux, Claude Code now works out whether it is running in a user namespace with no uid mapping, where every uid collapses to the overflow uid (usually 65534) or root is ambiguous. In that case it refuses to use the daemon socket and tells you to start with a mapping, for example unshare -Ur, because it cannot verify who owns the socket directory or who is on the other end.
- Reads
/proc/self/uid_mapand/proc/sys/kernel/overflowuid. - The
uid_mapparse is now a synchronousreadFileSyncmemoised into the process-namespace cache rather than an async read on every call, and is also used to translate container uids back to host uids. - Linux-only by construction, since it depends on those procfs paths. No feature flag.
refusing to use the daemon socket: this process runs in a user namespace without a uid mapping, so directory and peer ownership cannot be verified (start it with a mapping, e.g. unshare -Ur), uidsCollapse = null;
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Messages injected by a host are classified separately from peer messages
Both mention cross
-
v2.1.234
Cross-session control requests check ids more carefully
Both mention cross
-
v2.1.234
Notice acks now wait for the record to persist
Both mention cross