A bad --messaging-socket-path now fails startup instead of leaving your inbox quietly broken.
What's wrong with this entry?
When you pass an explicit socket path for peer messaging, Claude Code now checks the path and its directory up front and treats problems as startup errors rather than continuing with a quietly unusable inbox. The path must be absolute, free of .., and within the Unix socket path length limit, and the directory holding the socket must be a real directory you own privately at mode 0700, not a symlink. Key publication for peer authentication is held to the same standard.
- Missing directories are created privately, and the check refuses to descend through a directory owned by another user.
- A directory that is a symlink rather than a real directory is rejected with
--messaging-socket-path directory must be a real directory, not a symlink. - If authentication is required and the key peers use to authenticate cannot be published, startup fails with
peers could not authenticate, so the inbox was closed. Check that the session registry directory is writable by you., where previously the failure was logged and ignored. - Every one of these checks is gated on the flag being passed explicitly. When the socket path is chosen for you rather than requested, a key publication failure still logs and continues as before.
--messaging-socket-path directory must be a real directory, not a symlink, peers could not authenticate, so the inbox was closed. Check that the session registry directory is writable by you.
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.232
Clearer failures when the messaging socket path is unusable
Both mention socket path
-
v2.1.247
--messaging-socket-pathnow errors instead of silently doing nothingBoth mention socket path
-
v2.1.224
Session info reports the messaging socket path
Both mention socket path