Documentation
Changelog
D-411AI Assistants

Sessions started by an assistant

How the assistant spawns sessions, what you see, and how to step in.

Available on
Available onDesktopWeb PortalMobile
Reviewed
September 16, 2026
On this page

When an assistant needs to actually edit code or run commands, it spawns a session. The session has all the same controls as a session you started yourself, but the assistant is the one talking to the agent.

When does an assistant spawn a session?

Whenever the assistant wakes, a session is started so the underlying coding agent has somewhere to think and act. Wakes happen when:

  • You send a chat message.
  • A routine fires on its schedule.
  • A task gets assigned to the assistant.
  • A heartbeat or follow-up trigger comes in from another assistant or team member.

For a short reply or a memory update, the session may finish in seconds. For real coding work, it can run for minutes. Either way, the session shows up in your sidebar so you can follow along.

What you see

A new session appears in your sidebar, attributed to the assistant. The session title is auto-generated from the work it’s doing (often the first user message or task title).

In the assistant’s own Sessions tab, you’ll see the chronological list of sessions the assistant has launched, with status and outcome.

Delegated subagents

An assistant’s session can use gp_spawn_subagent to delegate work into an inline child card. Spawning that child is auto-approved; the child’s own questions and permission requests still appear for you to answer. Expand the card to follow its activity, or choose Open for the full child chat.

The child runs on the assistant session’s host. You can view and respond to it from desktop, portal, or mobile with full cloud relay access. When the assistant needs a separate workspace tab or a worker on another host, it uses gp_start_session, which requires approval. See Inline subagents and remote viewing.

Stepping in

Assistants don’t lock you out. While an assistant’s session is running, you can:

  • Read the transcript live.
  • Approve or deny pending tool calls.
  • Send your own follow-up message into the session.
  • Pause, stop, or resume.

If you send a message into the session, the next turn picks it up — the assistant’s plan and your input both feed in. This is the easiest way to redirect an assistant that’s headed the wrong way.

When the assistant’s session ends

When the session stops, the assistant posts a summary in chat. You’ll see something like “Finished. Made 3 files changes, ran the test suite, all green.” Linked tasks update to their next status.

If the session failed (test suite red, command errored), the assistant posts the failure summary and usually adds a follow-up task or note to its journal.

Approvals on assistant sessions

By default, approval requests from an assistant’s session go to you — the person who has access to the assistant. On a team-of-humans plan, approvals can fan out: anyone with assistant access sees the pending request.

Resuming the same session across wakes

Session continuity is Claude Code only today. With Claude Code, the assistant warm-resumes the same underlying agent session across wakes, so a chat message that arrives 10 minutes after the last work continues the existing conversation rather than starting fresh.

For Codex and Gemini, every wake starts a fresh agent session. Context still survives the cold start because the persona, constitution, memory, journal, and recent chat are loaded into the new session’s first prompt.

When the assistant’s persona or constitution changes, the next wake cold-starts a new session even on Claude Code, so the agent picks up the refreshed context.

On the portal

Same view. The assistant’s sessions appear in your Sessions list alongside sessions you started yourself, attributed to the assistant.

On mobile

You’ll see assistant-spawned sessions in the bottom Sessions tab. Pending approvals across all assistants show as a single notification badge.