`crossSessionInbound` silently discards out-of-enum values (e.g. "reject"), falling back to unset behaviour with no error or warning

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?

crossSessionInbound accepts only accept, hold, and refuse. Any other value is discarded and the session falls back to the unset behaviour. There is no error, no warning, and no log line, and the settings file still reads as though the session were configured.

The value I tried was "reject", which is the wrong word but not an obviously wrong word. It behaved exactly like leaving the key out.

This matters because of where the key gets typed. Two active threads currently tell readers to hand-edit crossSessionInbound in settings.json (#86298 and #86571), so the population most likely to hit this is people following advice about cross-session delivery. If someone reaches for it to opt a session out and writes reject, the setting silently does the opposite of what they intended.

The failure direction is what makes it worth reporting: it fails toward delivery, not toward blocking.

What Should Happen?

An out-of-enum value should surface somewhere. A startup warning naming the key and the accepted values would be enough. Failing closed would also be defensible for this particular setting, but I would not argue for that over a warning.

For comparison, defaultMode does report when it is ignored:

Ignoring defaultMode "bypassPermissions" from projectLocal tier — repo-committed settings can't default to bypassPermissions

crossSessionInbound produces nothing comparable.

Error Messages/Logs

None. That is the bug.

The declaration in the runtime:

crossSessionInbound: Hr(["accept","hold","refuse"]).optional().catch(void 0)

.catch(void 0) maps a schema failure to undefined, which is the unset case.

Steps to Reproduce

Two sessions, A and B, where A can send B a cross-session message.

1. Set "crossSessionInbound": "refuse" in ~/.claude/settings.json.
2. Make sure B's CLI starts after the edit, so it reads the new file.
3. Send B a message from A. It is blocked.
4. Change the value to "reject". Start B fresh again.
5. Send B another message. It is delivered, and B answers it.

Step 5 is the bug. reject is not in the enum, so it is dropped and B behaves as if the key were absent.

To confirm the value was actually read rather than ignored for some other reason, check that B's CLI process started after the file was written. In my run the edit was at 00:56:14 and B started at 00:56:42, so it read a file containing reject.

Claude Model

Opus 5

Is this a regression?

Not that I can tell. I have only tested 2.1.237.

Last Working Version

n/a

Claude Code Version

2.1.237, as bundled with desktop 1.34493.1

Platform

macOS desktop app

Operating System

macOS, Darwin 25.5.0

Terminal/Shell

Desktop app sessions, not a terminal shell

Additional Information

Context for triage, since this key is being discussed in several places right now: #86298 and #86571 both recommend setting crossSessionInbound, and the hold behaviour it controls is the subject of #85888, #85679, and #85678. This report is only about value validation. I am deliberately not making any claim here about when the gate holds a message, which I could not pin down and which those issues cover better.