One Atlarix session can review another's work before it lands. Not just read it — approve it, deny it, or replace it. Here is how cross-session review works, why it catches mistakes a single session misses, and how to set it up.
What cross-session review is
When a session has a pending permission request — a file edit waiting for approval, a plan waiting to be built — another session can see it in list_sessions and answer it with send_message. The reviewer can approve the request, deny it with a reason, or (for plans) replace it entirely. The target session sees who answered and proceeds accordingly.
Why two sessions catch more than one
A session that wrote the code is the worst reviewer of that code. It has the same context, the same assumptions, the same blind spots. A second session, started fresh or forked earlier, sees the change without the context that led to it. It asks the questions the first session assumed away.
How to set it up
Start two sessions in the same workspace. In the first, ask it to build something and let it reach a plan or a permission request. In the second, run list_sessions — you will see the first session with hasApproval: true or a plan awaiting approval. Send a message with review: true to attach the pending state, or answer directly with approval: <operationId> or plan: approve.
What the reviewer sees
list_sessions with plan_of shows another session's plan in full. For permission requests, the pendingApprovals field lists each request with its operationId, operation type, and summary. The reviewer can approve or deny each one individually, or approve the plan that would run them all.
What happens when the reviewer answers
An approval proceeds exactly as if the owner had clicked Approve. A denial stops the request and tells the target why. A plan replacement gives the target a new plan to work from. In every case, the target session shows a line saying who answered — the review is visible, not silent.
Limits
High-risk requests — those that could cause data loss or security issues — cannot be approved by a peer session. They need the owner. This is deliberate: a peer session is a contributor, not an administrator. The line is drawn at the request level, not the session level.
Cross-session review shipped in Atlarix 15.11. For the messaging primitives it builds on, see cross-session communication.
FAQ
Can one Atlarix session approve another's changes?
Yes. A session can approve, deny or replace another session's pending permission requests and plans, except for high-risk requests that need the owner.
Why use two AI sessions instead of one?
A second session sees the change without the context that led to it. It catches assumptions and mistakes the first session is blind to.
Top comments (1)
"A session that wrote the code is the worst reviewer of that code" is the line I'd underline. We see the same thing: a fresh reviewer without the author's context asks the questions the author assumed away. One thing we'd add: make the reviewer's verdict count for something. If a reviewer can flag a problem but the change still merges, the review is advice, not a check. Tying open high-severity findings to a merge block is where it starts paying off.