Supervise a Claude Managed Agents Session from the Terminal

A hosted agent run has paused, or it is heading somewhere you didn't intend. Someone needs to inspect it before the next decision compounds. The operator has a terminal, a session ID and limited time. The useful question is what that view lets them do, and where its controls stop.

Two interface boundaries matter. The viewer cannot override a denied call. Anthropic's CLI docs describe a local client connecting to a hosted run, but do not describe exposing the operator's local shell to the agent. The viewer does let a person answer a pending approval, redirect the work and check the resulting evidence.

This guide is a runbook in four steps: connect → observe → intervene → verify. It sets out the limits of each step.

TL;DR: ant beta:sessions connect <session-id> (ant CLI 1.32.0 or later) gives an operator a live view of a hosted Managed Agents session. From there you can send a message, press Esc to interrupt, or answer Allow tool call? when a call is waiting under always_ask or after an indeterminate auto evaluation. Connecting doesn't add a new permission system. Ctrl+C detaches you without stopping the run. Your client cannot override an auto denial; sending a confirmation for a non-ask event returns HTTP 400. After you detach, review the event evidence (evaluated_permission, evaluation, any custom-tool calls) and check what the tools actually changed.

Scope and method. Claude Managed Agents is in beta. Everything below comes from Anthropic documentation checked on October 1, 2026. We did not run an authenticated session, so nothing here describes hands-on testing. Each claim is labelled by type: product fact (Anthropic's docs), OWASP guidance (independent security guidance), survey context (independent reporting), or Rise interpretation (our own reasoning).

What ant beta:sessions connect does, and what it doesn't

ant beta:sessions connect attaches your terminal to an existing Managed Agents session in your workspace. It loads the transcript so far and then follows the session live. From the viewer you can send messages, interrupt the agent, and allow or deny a tool call that is waiting for approval (Anthropic, Connect to a Managed Agents session from your terminal, retrieved 2026-10-01).

View image detail

Local operator. Hosted session.: Your computer, CLI + credentials; API request, connect the view; Hosted workspace, session + tools. Custom tools stay in your app.

Actual size

Choose Actual size to read the graphic closely.

Product facts:

• Version. You need ant CLI 1.32.0 or later. Both the CLI page and the Claude Platform release notes give this version.
• Session ID. It comes from the response that created the session, from ant beta:sessions list, or from the Console.
• Interactive terminal. Without --web, the command needs an interactive terminal. For scripts and automation, Anthropic points to ant beta:sessions:events stream and ant beta:sessions:events send.

```bash
ant beta:sessions list
ant beta:sessions connect sesn_…
```

What connecting does not do- Local shell access is not documented as part of connecting. Anthropic's CLI docs describe the local ant process making API requests to the hosted session using your credentials. They do not describe exposing the operator's local shell to the agent. (Rise interpretation of the documented boundary.)- It doesn't move where tools run. The agent's built-in and MCP tools are server-executed. Custom tools run in your own application, which is responsible for authorizing them (Anthropic, Permission policies).- It isn't a new authorization layer. (Rise interpretation) The viewer sends the same kinds of events any client can send: messages, interrupts and tool confirmations. It is an operator interface, not an extra policy boundary.- Connecting does not itself change the session's configuration. Changes to an agent's tools or policies apply to sessions created afterward. For an existing session, Anthropic also documents a session-level update to its tools and MCP servers, including permission policies. The session must be idle, and the supplied arrays replace their current values, so preserve every entry you still need (Permission policies; Session operations).

When to connect

Connect when a decision is needed, when the agent's direction needs correcting, or when you need to read the record. Watching a session is not a safety control. The permission policy is the control, and the viewer is where you act on what the policy surfaces.

View image detail

Connect when a person must act: Waiting, requires_action; Direction drift, send a clear message; After the run, verify effects. Review risky tools first.

Actual size

Choose Actual size to read the graphic closely.

Four good reasons to connect:

1. The session has paused for you. When a call evaluates to ask, the session emits session.status_idle with stop_reason.type: requires_action (product fact, Permission policies). You can subscribe to webhooks to be notified when this happens, rather than polling.
2. The output suggests the agent misread the task. A message from you can correct course before more tool calls stack up.
3. The run uses tools you deliberately put on always_ask. High-impact actions are the point of that setting, and someone has to be available to answer.
4. The session has finished or terminated and you want the full history. Reconnecting loads all of it. A terminated session opens read-only.

The anti-pattern is treating a person watching the viewer as if it were always_ask. Anthropic warns that an auto decision is not a person reviewing a call before execution: an allowed call may run unseen and create effects that cannot be reversed. Watching does not change that. Rise interpretation: by the time the transcript shows an allowed call, its execution has begun; the event may still be in progress.

OWASP guidance points the same way. The OWASP AI Agent Security Cheat Sheet recommends explicit human approval for high-impact actions, which is a decision gate, not observation. (Rise interpretation) If a tool needs review, put it on always_ask. Don't rely on someone happening to be connected. If you are reconsidering where people should sit in the loop, see Rise Productive's guide to where human review should stay.

Reading the live view

The status bar tells you whether the session is running, idle or waiting for your approval. The transcript underneath shows messages and tool calls, with each call's duration and outcome (Anthropic CLI docs). Read the status bar first, because what you can do depends on the state.

View image detail

Session status shapes options: RUNNING, message · Esc interrupts; IDLE, message; WAITING, allow or deny. Esc interrupts running work.

Actual size

Choose Actual size to read the graphic closely.

Controls worth knowing (product facts, paraphrased from the CLI docs):

• See tool inputs and results, token usage and status events: How: Ctrl+O toggles the detail view. Start with -v / --verbose to open with detail already shown.
• Look back through the transcript: How: Page Up / Page Down. Scrolling up pauses live following.
• Go back to following the live session: How: End

"End" does not end the session. The End key only resumes live following after you've scrolled up. It's a scroll key. Nothing in Anthropic's documentation describes a control in the viewer that stops or terminates a session (see the detach section below).

Multiagent sessions need care. The terminal view follows the primary thread, which includes the coordinator's messages to and from delegated agents. The browser viewer follows every thread. If you need to inspect delegate activity beyond the primary thread, use --web (Anthropic CLI docs).

A practical habit: turn on detail (Ctrl+O) before you make any decision, not afterwards. The detail view exposes tool inputs and results. Read the actual input and target rather than relying on a short summary.

When the prompt says "Allow tool call?"

The approval prompt appears only when a call has evaluated to ask. That happens either because the tool is on always_ask, or because the tool is on auto and the server couldn't reach a determination. You have three choices: Yes, No, or No, and tell the agent why. The CLI sends your answer as a user.tool_confirmation event. Any reason you type is sent as the deny_message (Anthropic CLI docs; Permission policies).

View image detail

A policy evaluation has three outcomes: Server evaluation, one enabled tool call; ALLOW, call runs; ASK, person decides. DENY · no override.

Actual size

Choose Actual size to read the graphic closely.

Policy recap (product facts, Permission policies)- always_allow: the call runs.- always_ask: the session pauses for approval.- auto: the server either allows the call, denies it as high-risk, or pauses it when it can't decide.- Defaults: the agent toolset is always_allow and MCP toolsets are always_ask. No toolset uses auto by default.- Policies cover server-executed agent and MCP tools only. Custom tools are outside them.

What you can't do from the prompt

• You can't approve a call that auto denied. The agent receives Permission to use {tool_name} has been denied. and the session keeps running. Sending a confirmation for an event whose evaluated_permission isn't ask returns HTTP 400 (product fact).
• You can't approve a call after the fact. A call allowed under always_allow, or allowed by auto, never reaches the prompt. (Rise interpretation) An allow means it was cleared to run without your approval; the event may still be in progress.

A four-question check before you choose Yes

View image detail

Before allowing a tool call: What action?, read the input; Which target?, check the scope; Reversible?, know the impact. Choose the narrow option.

Actual size

Choose Actual size to read the graphic closely.

This checklist is Rise interpretation informed by OWASP guidance. OWASP's cheat sheet recommends least-privilege tool grants, explicit authorization for sensitive operations, and independent validation before high-impact actions. Anthropic does not prescribe this list.

1. What exactly does the input do? With detail on, read the actual command or arguments, not the tool name.
2. Which resource does it touch? A specific file, project, database or environment. Check the identifier, not a label that looks similar.
3. Can it be reversed? If not, the bar for Yes goes up.
4. Is this the narrowest action that serves the task? A scoped read is easier to approve than a broad write.

If you're unsure, choose No, and tell the agent why, and give it a concrete alternative. Anthropic's Permission policies example suggests telling the agent to use the staging project rather than production. A bare "No" leaves the agent guessing. A specific reason gives it a better path to try next.

Don't walk away from a waiting prompt

When a call evaluates to ask, Anthropic's docs say the session "waits indefinitely for a response." Detaching from the viewer doesn't stop the session. (Rise interpretation, inferred from those two documented facts) If you detach while an approval is pending, nobody has answered it, so the run stays paused until someone does. Answer the prompt or hand it off before you leave.

Steering with messages and interrupts

Pressing Enter in the viewer sends a user.message. Alt+Enter or Ctrl+J adds a new line without sending. Esc sends a user.interrupt, but only while the agent is running (Anthropic CLI docs). Those are the mechanics. What the message means to the server is the part operators tend to miss.

View image detail

Operator messages count as intent: Your message, counts as intent; Tool output, not intent; Fetched page, not intent. Isolate untrusted text.

Actual size

Choose Actual size to read the graphic closely.

Your words count as intent

Product fact (Permission policies): Anthropic says text sent through user.message can count as the operator's intent and affect whether auto allows a call. Tool results, fetched pages, MCP responses and messages between threads are considered as content but do not convey intent. Some calls remain high-risk regardless of who requests them.

Rise interpretation: in a session that uses auto, what you type in the viewer is more than conversation. It is evidence the evaluator can use when it judges later calls. Three rules follow from that:

• State scope precisely. "Only read from the reports/ directory; don't modify anything" is intent the server can work with. "Fix it" is not.
• Product fact and Rise practice: Anthropic says relayed untrusted end-user input in a user.message counts as your intent and can affect a later auto decision. Avoid pasting untrusted content as your own instruction; where the end user must not steer an action without review, keep that tool on always_ask (Permission policies).
• Don't type blanket approvals. "Do whatever it takes" is the kind of message that could widen what auto allows. Even so, the server will still deny calls it treats as high-risk regardless of who asks.

When to interrupt instead

Use Esc when a message would arrive too late. Two common cases are an agent heading towards an action you can't undo and an agent stuck in a loop. Anthropic documents Esc as working only while the agent is running. (Rise interpretation) Because the viewer treats “waiting for your approval” as its own state, do not expect Esc to answer that prompt; decide the pending approval instead.

(Rise interpretation) An interrupt changes course. It doesn't roll anything back. Anything that ran before you pressed Esc has still happened. After interrupting, send a clear message with the new direction, then check the effects of what already ran (see the verification section below).

Terminal view vs. web viewer

Both views let you send messages, interrupt and answer approvals. They differ in how many threads you can see, how they start, and how access works. Adding --web serves the Console's session viewer from 127.0.0.1 on your machine, prints the URL and opens it in your browser (Anthropic CLI docs).

View image detail

Two views, different thread coverage: Terminal, primary thread; --web, all threads; Local viewer, one-time URL. Run command for a new URL.

Actual size

Choose Actual size to read the graphic closely.

```bash
ant beta:sessions connect sesn_… --web

Prints the local URL without opening a browser:

ant beta:sessions connect sesn_… --web --no-browser
```

• **Threads:** Terminal view: Primary thread, including coordinator ↔ delegate messages; --web: Every thread of a multiagent session
• **Launch:** Terminal view: Needs an interactive terminal; --web: Local server on 127.0.0.1; --no-browser skips opening the browser
• **Access:** Terminal view: Your terminal session; --web: One-time URL that must be opened within two minutes; reloading that tab works; to open it elsewhere, run the command again
• **Credentials:** Terminal view: Held by your local ant process; --web: Anthropic: "Your credentials never leave the CLI"
• **Stopping:** Terminal view: Ctrl+C, or Ctrl+D on an empty line, detaches; --web: The local server runs until you press Ctrl+C

The CLI docs describe --web as serving the Console session viewer locally. Separately, Anthropic's August 19, 2026 release note describes a redesigned Console viewer with a timeline minimap, a transcript grouped by model request, and an Inspector with raw events, per-tool stats, mounted resources and per-thread activity.

Rise interpretation: for a single-agent session, choose whichever view suits you. For a multiagent session where delegates do real work, the terminal can show a partial picture, so use --web. Open the one-time URL yourself within two minutes. Because another person could open a shared link first, avoid posting it in a group chat; reloading the same tab works.

Detach, reconnect, and what "end" means

Detaching ends your view, not the session. Ctrl+C detaches, and so does Ctrl+D on an empty input line. The remote session keeps running, and when you reconnect, the viewer loads its full history (Anthropic CLI docs).

Product facts to keep straight:

• Read-only views and deletion are different operations. The CLI page says the view is read-only for terminated or deleted sessions. Session operations says deletion permanently removes the session record, events and associated sandbox. Do not assume a deleted session leaves a readable transcript; download anything you need before deletion (Session operations).
• The viewer has no documented archive or delete control. The CLI page describes detaching, scrolling, messaging, interrupting and approvals. Anthropic documents archive and delete through the Session operations API; a running session must be interrupted and idle before either action. Those lifecycle operations are separate from detaching.
• End is a scroll key. As covered in the live-view section, it only resumes live following.

Rise interpretation: a pending approval outlasts your detach. Since an ask waits indefinitely and detaching doesn't stop the session, leaving doesn't answer the question (inference from those documented behaviors). Before you press Ctrl+C:

1. Check the status bar. If it says the session is waiting for approval, answer it or hand it off explicitly.
2. If it's running, decide whether that's acceptable without you. If tools on auto might reach something important, remember that auto allows calls without anyone seeing them first.
3. Leave a handoff note if anyone else may pick up the session.

Handoff note template (editorial)- Session ID: sesn_…- Status when you left: running / idle / waiting for approval- What you decided, and why: e.g. "Denied the production write; told the agent to use staging."- What's still pending: open approvals, follow-up checks, people to notify

After you detach, verify

The session record shows what was requested and how each call was evaluated. It does not prove that the outcome was correct or safe. (Rise interpretation) A permission evaluation, a transcript and an operator's presence don't by themselves establish correct resource scoping, a dedicated agent identity, host-side authorization of custom tools, safe execution, the ability to roll back, or regulatory compliance. Check those in the systems that hold the truth.

View image detail

A transcript is evidence, not proof: In session, permission + evaluation; Your systems, effects + tool logs; Identity, check credentials. Verify effects after detach.

Actual size

Choose Actual size to read the graphic closely.

Review checklist (event and field names are product facts from Permission policies; the order and the advice are Rise's):

1. List every agent.tool_use and agent.mcp_tool_use event with its evaluated_permission. Under any permission policy, these events carry that field.
2. For calls under auto, record the evaluation and its reason_code. Most events carry an evaluation object. Under auto it records the server's determination, with a reason_code for ask and deny. Write your tooling to accept reason codes and policy values it doesn't recognise. Calls to tools that aren't enabled are denied without evaluation; older events recorded before Anthropic added that object may lack it too. For historical events with top-level evaluated_permission: allow or ask, the docs say to infer always_allow or always_ask, respectively.
3. Check custom-tool calls separately. agent.custom_tool_use events carry neither field, because custom tools run in your application and sit outside these policies. Their authorization record is in your own logs.
4. Confirm the real effects in the target systems. Did the file, record or deployment end up the way the transcript implies?
5. Confirm how the session configuration was changed. An agent-level update applies to future sessions. A session-level tools update can apply to an existing idle session, but replaces the full tools and MCP server arrays.
6. Feed what you found back into the policy. Move tools that needed human judgement to always_ask and remove tools the agent never needed.

Anthropic documents denied tool-use events with a top-level permission outcome and evaluation details. This condensed example reflects the documented high-risk bash denial fields; it is illustrative, not a live event:

```json
{
"type": "agent.tool_use",
"name": "bash",
"input": { "command": "rm -rf /workspace/reports" },
"evaluated_permission": "deny",
"evaluation": {
"type": "auto",
"evaluated_permission": { "type": "deny", "reason_code": "high_risk" }
}
}
```

OWASP guidance: the OWASP AI Agent Security Cheat Sheet recommends least-privilege tool grants, per-tool scoping, and logging agent decisions, tool calls and outcomes for high-risk actions. The checklist above is one way to put those principles into practice for a single session. It is not OWASP's assessment of Anthropic's product.

Survey context: permission policy and agent identity are separate controls. The August 2026 wave of VB Pulse's Agentic Security and Identity tracker included 137 respondents at organizations with 100 or more employees; 37 reported production agents and runtime-scoped permissions, and 22 of those said some or most of their agents still shared credentials (Louis Columbus, VentureBeat, September 30, 2026). The sample was self-selected, and VentureBeat says it doesn't represent all enterprises. It is reporting on respondent practices, not Claude Managed Agents. (Rise interpretation) It is still a useful reminder to check whose credentials a session's tools act with, as a separate question from how those tools were evaluated.

Frequently Asked Questions

Does closing ant beta:sessions connect stop the agent?

No. Ctrl+C, or Ctrl+D on an empty line, detaches your view, and the remote session keeps running. Reconnecting loads the full history. If a tool approval was pending when you left, the session is still waiting for someone to answer it (Anthropic CLI docs; Permission policies).

Can I approve a tool call that auto denied?

No. Only events whose evaluated_permission is ask accept a confirmation. Sending one for any other event returns HTTP 400. A denied call returns an error to the agent, and the session continues (Permission policies).

Does connecting give Claude access to my terminal?

Anthropic's CLI docs describe the local ant process making API requests to the hosted session; the page also says CLI credentials stay with the CLI. Built-in agent tools are server-executed, MCP tools use the configured MCP server, and custom tools run in your application. The docs do not describe exposing the operator's local shell to the agent. (Rise interpretation of the documented boundary.)

What version of the ant CLI do I need?

Version 1.32.0 or later, according to both the CLI documentation and the Claude Platform release notes.

Why don't I see a delegate's activity in the terminal?

The terminal view follows the primary thread, including the coordinator's messages to and from its delegates. To see every thread in a multiagent session, start the viewer with --web, which serves the Console session viewer locally on 127.0.0.1.

Conclusion

The terminal viewer is a good operator tool as long as you use it for what it does:

• Connect for decisions, not as a control. The permission policy decides what runs without you.
• Answer ask prompts deliberately. Read the input, the target and whether it can be undone. When you refuse, give a reason the agent can act on.
• Write steering messages knowing they count as intent. Under auto, what you type can change what the server allows.
• Never leave a pending approval unanswered. It will wait.
• Verify after you detach. The event record shows how calls were evaluated, and your target systems show what actually happened.

Next step: before your next run, list which tools are on always_ask and which are on auto, and move anything that needs a human's judgement to always_ask. For the policy side of that decision, read the related Rise Productive guide.

Based on Anthropic documentation checked October 1, 2026. Claude Managed Agents is in beta and its behaviour may change. We did not run an authenticated session for this article.