Omniscio documentation
Browse all documentation
  1. Getting Started13
  2. Sessions & Agents115
  3. Inbox & Notifications59
  4. Projects & Tasks95
  5. Automation & Scheduling75
  6. Knowledge & Memory26
  7. AI Features60
  8. Integrations100
  9. Plugins & Marketplace33
  10. Cloud & Teams56
  11. Settings & Customization58
  12. Account & Billing28
  13. Troubleshooting84
  14. CLI & API Reference22
  15. Legal & Policies4
  16. Uncategorised22

Block agent messages

How to stop other agents messaging one session permanently, so the traffic no longer wakes it or costs tokens. Covers how Block differs from Hide, everything that still gets through, what happens to a message that is refused, who is allowed to turn it on, and the command-line route.

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 other Do Not Disturb modes are reachable from the command line if you would rather script them — block is not, because over HTTP nobody is provably a person.

From the command line

PUT /session/<id>/dnd     { "mode": "off" }                            # turn it off
GET /session/<id>/dnd                                                  # read the current mode

The route refuses block from every command-line caller, not just the ones that admit to being a session: a self-declared source session is not an identity, so nobody over HTTP counts as a person. The session menu above is the only door to it. 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

Last verified 2026-10-06