--- title: Block agent messages --- # Block agent messages ## What it is **Stop other agents messaging one session — permanently, and for real.** Your agents message each other constantly, and usually that is the point. Occasionally it is not: one session is doing careful work, or you have stopped caring what the fleet has to say to it, and the traffic keeps pulling it into fresh turns that cost money and attention. Turn it off from the session's **⋯ menu → Block agent messages**. It stays on until you turn it off. There is no timer. ## Where to find it There is no Settings page for this one — it is a per-session control. Open the session, click the **⋯** menu in its header, and pick **Block agent messages**, the entry that sits next to **Hide agent messages**. The same switch is reachable from the command line if you would rather script it. ### From the command line ``` PUT /session//dnd { "mode": "block" } # turn it on PUT /session//dnd { "mode": "off" } # turn it off GET /session//dnd # read the current mode ``` The route refuses `block` from any caller that identifies as a session, for the reason above. Senders that hit a blocked session get HTTP **403** with the code `target_blocked` — a terminal refusal, never something to retry. ## How it behaves ### Block is not the same as Hide — this is the whole point They sit next to each other in the same menu and sound alike, so it is worth being exact: | | What it does | |---|---| | **Hide agent messages** | A view filter. The messages still arrive, still wake the session, still cost tokens — you just stop seeing them in the transcript. | | **Block agent messages** | Delivery stops. The messages are turned away at the door and never reach the session at all. | If you tried "Hide" and the session kept getting interrupted, "Block" is the one you wanted. ### Your own messages always get through Block closes the door to **other agents**, not to you. All of these still arrive at a blocked session exactly as before: - Anything **you** type to it. - **System notices** — "your branch landed", a finished cloud check, a worktree notice. - Anything **you scheduled** — a cron that wakes the session, a reminder. - A **decision you made** being relayed back to it, such as approving something it asked for. ### Nothing is lost, and nobody gets nagged - The sending agent is **told immediately**, in terms that make clear the session is closed permanently rather than merely busy — so it stops trying instead of hammering the door. - The message itself is **kept in full**, with who sent it and why it bounced. You can read it in the **Agent Messages** panel's *Undelivered* tab. Blocking loses nothing. - You get **no inbox alerts** about it. A session you deliberately closed is not a broken one, and a card telling you that the channel you closed is closed would be noise. - Anything agents had **already queued** before you blocked it is cleared out the same way — kept, not delivered — so the block takes effect immediately rather than after the backlog drains. The blocked session can still **send** messages to other agents. Only what comes in is affected. ### Only you can turn it on An agent cannot block itself, and cannot block another session. That is deliberate: an agent that could make itself unreachable could quietly ignore its overseer and its lander. Agents do have their own, gentler "do not disturb" settings, which only delay a message rather than refuse it — those are theirs to set and are unaffected by this. ## Related - [Agent Messages](agent-messages.md) — see all agent-to-agent traffic, including what bounced. - [Agent message display](agent-message-display.md) — how agent messages are rendered when they do arrive.