Manage sessions
This guide ties together the four common session workflows in Jarvis: launch work, send follow-up instructions, inspect current state, and respond when a worker is blocked.
Use Jarvis as a single control surface for coding agent work, whether the session was launched by Jarvis or discovered from a local runtime.
Prerequisites
Section titled “Prerequisites”- Jarvis is running and you can open the docs-site-supported UI or desktop app.
- Jarvis is running and you can open the web UI or desktop app.
- At least one supported runtime is installed and authenticated.
- You understand the difference between a managed session and a local runtime session.
-
Choose the session source Start a new managed session when you want Jarvis to supervise the work from the beginning. Use a discovered local runtime session when you already started the work in a terminal and want Jarvis to inspect or follow it.
-
Open the session list Review the available sessions and note their runtime, current state, and whether a human decision is pending.
-
Launch or select a session Launch a new worker for fresh work, or open an existing session to continue supervising it.
-
Dispatch follow-up work Send the next instruction when a worker finishes a step, needs clarification, or should take a new branch of work.
-
Use signals, not raw transcript spam Watch summary capsules for compact status and MCP reports for active worker updates. Open the full session only when you need detailed debugging.
-
Clear blockers quickly If a worker reports a blocker or asks a question, answer in the main chat or dispatch a clear next step so the session can resume.
-
Reinspect before reusing a session Before you dispatch more work to an old session, verify that its runtime state still matches your expectation.
Common Session States
Section titled “Common Session States”- Running
- Agent is actively producing output or executing work.
- Waiting
- Agent is waiting for a tool, model, or external process.
- Blocked
- Agent needs human input or cannot proceed safely.
- Idle
- Session is available but not currently progressing.
- Human
- A user decision or remote response is needed.
- Agent
- A worker or brain session reported state through MCP.
Verify
Section titled “Verify”You are using session management correctly when:
- you can distinguish managed sessions from local runtime sessions
- a new worker appears in the session list after launch
- progress is visible through summary capsules or MCP reports
- you can open an existing session and understand whether it is safe to reuse
- a blocker can be resolved from the main chat without reconstructing the entire terminal history
Troubleshooting
Section titled “Troubleshooting”A session is visible but not controllable
Section titled “A session is visible but not controllable”It is likely a discovered local runtime session with limited attachment or follow-up support. Inspect it first, then decide whether to continue there or launch a fresh managed session.
A worker looks stuck but no blocker was reported
Section titled “A worker looks stuck but no blocker was reported”Check the summary capsule and then inspect the full session. Not every runtime step emits an MCP update, so the worker may still be running or waiting on an external process.
I answered the question, but the worker did not continue
Section titled “I answered the question, but the worker did not continue”Send an explicit follow-up instruction through dispatch instead of assuming the worker inferred the next step from context alone.
Too much session detail is showing up in chat
Section titled “Too much session detail is showing up in chat”Prefer capsule-level supervision for routine monitoring and open the full session only when you are debugging or validating a risky change.