{"version":"2.1.248","anchor":"claude-code-refuses-its-daemon-socket-inside-an-unmapped-use","canonical_anchor":"claude-code-refuses-its-daemon-socket-inside-an-unmapped-use","heading":"Claude Code refuses its daemon socket inside an unmapped user namespace","tier":"notice","area":"Cross-Session Messaging","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/claude-code-refuses-its-daemon-socket-inside-an-unmapped-use","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Claude Code refuses its daemon socket inside an unmapped user namespace\n\nOn Linux, an unmapped user namespace now refuses the daemon socket and suggests unshare -Ur.\n\n**What**\n\nOn 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.\n\n**Details**\n\n- Reads `\/proc\/self\/uid_map` and `\/proc\/sys\/kernel\/overflowuid`.\n- The `uid_map` parse is now a synchronous `readFileSync` memoised 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.\n- Linux-only by construction, since it depends on those procfs paths. No feature flag.\n\n**Evidence**\n\n`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;`\n\n- Area: Cross-Session Messaging\n- Names: `unshare -Ur`\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}