[FEATURE] Cross-session send cap (10 per human input) is not configurable and ignores inbound human-originated messages

Adding a second data point (macOS, Claude Desktop (Claude 2.2553.1 (c38127) 2026-09-18T00:41:58.000Z) Code tab; this issue is labelled platform:windows, so this seems to be cross-platform) and a suggestion.

Use case. I run two Claude Code sessions in the Desktop Code tab as a pair, an implementer and an independent reviewer, working through a queue of tasks that is meant to keep going while I'm away (overnight, for example). The cap stalls that pair: I only type in one of the two sessions, so the other reaches 10 sends and stays paused until I type in that specific session. It happened three times in under two hours today.

Observation (from tool results in my own sessions, so anecdotal): refused sends appear to keep incrementing the counter (10, 11, 12), so the count reflects attempts rather than delivered messages.

Suggestion. The CLI-native route already handles loops without a human-input counter: the docs describe a rapid-burst refusal at the sender, a per-sender rate limit, dropping of identical repeats and a bounded queue (https://code.claude.com/docs/en/cross-session-messaging). Something similar here, or a configurable threshold with an opt-out for unattended multi-session workflows, would keep the loop protection without stopping legitimate long-running work.

+1 to the other requests above: reset the count on an inbound human-originated message, and document the number and the reset condition.

+1, and I want to be direct about the cost of this.

For about ten weeks I've been building a supervised, multi-session engineering system on Claude Code Desktop: one coordinating session, worker sessions that draft and review through pinned tools, a monitoring session, and a written handover protocol so work survives context compaction. Every change goes through independent review before it's used. Every job leaves an audit row. Consequential steps wait for my approval. It is the opposite of a runaway loop. It's deliberately governed, and it's logged end to end. With Opus 5.5 and its efficiency it finally came together with all the work that had previously been done.

Last night was the first night it ran at full pace. In a couple of hours it verified and repaired a 53 GB model download, cleared four review cycles and handed work between sessions cleanly. Then, about 30 minutes after I stepped away, the coordinator hit:

"Not delivered: this session has already messaged Claude Desktop sessions 10 times since your user last typed here… Paused until your user's next message in this session."

Everything stopped. The workers sat idle and the monitoring session missed its check-in. Nothing moved until I came back and typed a throwaway line. The scheduled prompts I created in that session to drive it overnight don't count. The cap isn't documented, it can't be configured, and it only shows up once work has already stalled.

The runs this system exists for are 8-12 hours, overnight, while I sleep. With a 10-message ceiling that only a human keystroke resets, that is simply impossible. Four weeks of work toward unattended operation now depends on me waking up to press Enter.

I understand why the cap exists, and I want that protection for genuinely runaway loops. But it can't tell a runaway loop from a supervised system doing exactly what its owner built it to do. Please give us one of:

1. A configurable limit (setting or managed setting, e.g. crossSessionSendLimit), ideally as a rate (N per hour) instead of per keystroke.
2. Count scheduled prompts the user created in that session as user activity for the reset.
3. An explicit per-session opt-in for supervised orchestration, with every send logged.
4. At minimum: document the cap and its reset rule, and warn before the pause, not after.

Happy to share logs with the team.

+1, with one more data point from a supervised overnight run (macOS, Claude Desktop Code tab, Opus 5.5, all sessions in auto mode).

Setup. One coordinator session drives about a dozen worker sessions (one worktree each) through a closed protocol: the coordinator sends a task, each worker reports back READY / QUESTION / BLOCKED, and the coordinator answers from written decision rules. Every decision is logged. Workers can't push or merge; the coordinator pushes only to an internal remote after local validation. I set this up with the coordinator, approved everything up front, then went to sleep.

What happened.

• The cap was hit within about 40 minutes of my last message: 10 task messages, one per worker. The 11th worker never started, and the coordinator could no longer answer workers' questions.
• A message I typed while the coordinator was mid-turn did not reset the counter. Only a message typed after its turn ended did.
• Refused attempts keep incrementing the count (11, 12), as DMcGav reported.
• The same thing happened on two earlier nights, on the same setup.
• The only way forward was to move the remaining work into in-process subagents inside the coordinator, which aren't subject to the cap. That works, but it defeats the point of separate worker sessions with their own context and worktree.

What would fix it for us (any one):

1. A configurable limit, ideally a rate (N per hour) and per session, e.g. crossSessionSendLimit.
2. An explicit per-session opt-in for supervised orchestration, with every send logged, so a runaway loop still stops sessions that didn't opt in.
3. Count any human input in the session as a reset, including a message queued mid-turn and a scheduled prompt the user created.
4. At minimum, document the number and the reset rule, and show a warning before the pause (for example at 8/10), not after.

The loop guard is a good default. It just can't tell a runaway loop from a coordinator its owner set up and approved.