Make the cross-session send pause ("messaged Claude Desktop sessions 10 times since your user last typed") a configurable setting

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

In the Claude desktop app (Code tab, Windows 11), a session that has sent about 10 messages to other sessions since the user last typed in that session is stopped with:

Not delivered: this session has already messaged Claude Desktop sessions 10 times since your user last typed here, which looks like sessions messaging each other automatically. Paused until your user's next message in this session.

We run long unattended programs across three Windows machines. A coordinating session directs several worker sessions, on the same machine and over Remote Control, and the workers report back as they finish.

When a worker hits the pause overnight, it stops reporting. Its replies wait for hours (once for three days) until someone types in that exact session. From the other side, a paused session looks exactly like a stuck one, so the coordinator cannot tell "blocked" from "broken".

Every refused attempt also counts toward the limit, so a retry makes it worse.

The default makes sense for people who do not run unattended multi-session work. For those who do, a fixed limit with no way to change it breaks the workflow.

Proposed Solution

1. Keep 10 as the default for people who do not need more.
2. Make the limit a setting: a number, or off, in settings.json and in the app's settings.
3. When it is raised or turned off, show a caution prompt the user must confirm, the same way bypass permissions mode is confirmed.
4. Document the limit on the cross-session messaging page (https://code.claude.com/docs/en/cross-session-messaging). Today that page lists the size, burst and loop limits and the crossSessionInbound, isolatePeerMachines and dialogExpiry settings, but not this pause.
5. When a session is paused, show it on the session card and send a notification, so one word typed from the phone can release it.

Alternative Solutions

• Typing one word in each paused session, including from the phone through Remote Control. Works, but needs a human awake and watching every session.
• Restarting Claude, which resets the count. Heavy, and interrupts the running work.
• Batching to one message per peer per round, and reporting through shared files that the coordinator reads instead of messages. Reduces sends but does not remove the stop.
• None of the documented settings (crossSessionInbound, isolatePeerMachines, dialogExpiry) changes this pause.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. At night we start a coordinator session on machine A and leave it unattended.
2. It hands work to four worker sessions: two on machine A, two on machine B over Remote Control.
3. Each worker sends status updates and a final report back to the coordinator as it finishes each step.
4. After about 10 sends, a worker is paused. Its report sits unsent.
5. The coordinator sees a silent worker, cannot tell whether it is stuck, and the dependent steps wait.
6. In the morning we find the work finished hours ago, but nothing downstream moved because the report never went out.

With a configurable limit (for example 50, or off, confirmed through a caution prompt), the run would complete overnight.

Additional Context

What we measured:

1. Inbound messages are never blocked. Only sending is.
2. The count resets when we type in that session, or when Claude restarts. A slash command alone did not reset it, and a message typed during a running turn released only 2 more sends.
3. The sessions we type in most rarely hit it. The worker sessions we seldom type in hit it first.

Environment: Claude desktop app with Claude Code, Windows 11, Team plan, Remote Control on, sessions in bypass permissions mode.