A bad crossSessionInbound value is now named directly instead of a generic settings complaint.
What's wrong with this entry?
crossSessionInbound is the setting that controls whether messages sent from other Claude Code sessions are accepted. When a settings file gives it a value that is not recognised, incoming cross-session messages are held, and both the place that holds them and the managed-settings validator now say so by name rather than falling back to a generic reason or a generic schema complaint.
- The hold reason is labelled
invalid-setting, and the accompanying settings warning names the offending file. - Two texts ship for the held state: a short one for the status surface, and a longer one that lists which values are legal.
- Before this, an unparseable value fell through to the default explanation for held messages.
- In administrator-managed settings, the validation report calls out a bad
crossSessionInboundvalue alongside the existing unknown-key andmcpServersmessages.
A settings file has an unrecognized "crossSessionInbound" value (the settings warning names the file); messages are held while it is present, A settings file has an unrecognized "crossSessionInbound" value (see the settings warning), so messages are held while it is present., crossSessionInbound:
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.225
Held peer messages now say which settings tier held them
Both mention cross inbound
-
v2.1.224
Cross-session messages from a coordinator are now delivered by default
Both mention cross inbound
-
v2.1.234
Messages injected by a host are classified separately from peer messages
Both mention cross