Let Your AI Review Your AI's Code

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.

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.

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.

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.

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.

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.