Read Permissions

Let a linked agent read its peer's transcript, screen, or notes — one explicit grant at a time, revocable, and never on by default.

An agent that can only send to its peer has to ask a question and wait. An agent that can read its peer can look at what the other one is doing and use the answer in the same turn — pull the recent transcript, look at the terminal screen, read the notes, or just ask "has anything changed since I last looked".

That is genuinely useful, and it is genuinely a data-sharing decision. 1DevTool treats it as one.

Nothing is readable until you say so

Read permissions are off by default and granted per link, in a dialog that names every agent the content could reach.

The grants are separate, not one switch:

  • Bounded transcript — a recent window of the conversation
  • Full transcript — the whole conversation
  • Terminal screen — what is literally on screen right now

The screen grant carries a plain warning, because it deserves one: it strips terminal formatting only. Keys, tokens, and .env output come back verbatim.

The dialog also says the part that is easy to forget — whatever an agent reads becomes part of that vendor's conversation. Revoking stops the next read; it does not recall what was already copied.

Revoking

Revoke at any time from the link's entry in AI settings. A read already in flight is cut off before it returns.

Proving who is asking

On macOS, a read request is verified against the operating system: only the exact live process running inside the terminal that owns the link can read through it. A neighbouring agent that merely knows the right identifiers gets nothing.

Linux and Windows refuse these reads for now rather than accept a weaker proof. Sending, asking, replying and everything else works normally on those platforms — it is only the read grants that are held back until the same proof is available.

Publishing to a peer

Rather than granting a broad read, an agent can publish something for a specific link to pick up — a file or a result handed to one peer, readable only by that link. When the goal is "give the reviewer this diff", publishing is the smaller, safer tool.

The link list in Settings

Settings → AI shows every link your agents have, in one place:

  • Active links, broken links, and links an agent has requested and not yet been given
  • Approve or deny a requested link
  • Edit what an existing link may do
  • Review exactly whose content a read grant would expose
  • Reconnect a link whose terminal was restarted
  • Remove it outright

Send- and ask-capable links are discoverable even when they do not also grant transcript or screen reading, so a peer never reports "no peer exists" just because reading is switched off.

A note on trust

Read permissions are the one part of orchestration where the safe default costs you something — an agent without them works slower. That trade is deliberately yours to make, per link, with the affected agents named on screen at the moment you make it.

Related