First coding session

This guide walks through the first runtime-backed session you launch from Jarvis. The goal is not to finish a large task. The goal is to confirm that:

• Jarvis can launch a runtime from the UI
• progress appears in the main chat and the session view
• blocked or human-input states are visible
• you know where to look when a session needs help

Before you start

Make sure all of the following are true:

• Jarvis is already running locally
• you can open the UI and authenticate with your API key
• at least one runtime CLI is installed on this machine
• that runtime CLI is already authenticated outside Jarvis

If no runtime is ready, Jarvis can still run as a chat workspace, but the coding-session flow on this page will stop at runtime availability.

Launch a small, observable task

1. Open the Jarvis UI in your browser.
2. In the chat composer, choose a coding runtime such as Codex, Claude Code, or OpenCode.
3. Send a short task that is easy to verify, for example: Create a file named scratch.txt in the current workspace and write one sentence explaining that this is a Jarvis runtime smoke test.
4. Wait for Jarvis to create a coding session linked to that request.

If the runtime selector falls back to Auto or shows your preferred runtime as unavailable, stop and fix the local runtime CLI installation or authentication before continuing.

Watch progress in the main chat

When the worker starts, Jarvis should surface the session in the main chat.

Look for these signals:

• a session-linked response in the chat thread
• progress cards or worker updates as the runtime moves through the task
• a route into the dedicated coding-session view

Jarvis is designed to keep the main conversation readable. You should see compact progress reporting in chat rather than a full raw terminal transcript.

Open the dedicated session view

From the chat thread or the sessions area, open the coding session detail page.

In that view, confirm that you can inspect:

• the runtime name
• current session status
• terminal output or session snapshot
• replayable timeline or event history

This is the view to use when you need to answer the question, “What is the worker doing right now?”

Understand blocked and human-input states

Jarvis workers can report more than generic progress. A session can also explicitly surface that it is blocked or needs a human decision.

Typical cases include:

• the runtime needs clarification before changing code
• the task requires permission or a product decision
• the runtime hit an environment error it cannot resolve by itself

When that happens, Jarvis should surface the state in the main chat and in the session context instead of silently stalling.

What a healthy blocked flow looks like

A useful blocked state is explicit: the session says what it needs, you answer once, and the work continues. A silent session with no updates is the unhealthy case to investigate.

Respond when the worker needs you

Use the same UI that surfaced the question:

1. Read the progress or blocked message in the main chat.
2. Answer with the missing instruction, approval, or correction.
3. If you are already inside the coding-session view, use the visible intervention or reply path there when available.
4. Watch for the session to resume and emit a new progress update.

For a first smoke test, a simple reply such as “Proceed”, “Use the existing style in this repository”, or “Do not modify any file outside the current workspace” is enough to confirm the handoff path works.

Check logs when something looks wrong

There are three places to inspect problems:

1. Main chat: good for progress, blocked messages, and human-facing summaries
2. Coding-session detail view: good for terminal output, replay, and session-specific history
3. Backend logs on disk: good for startup errors, runtime launch failures, or transport-level issues

Local backend logs are written to:

data/logs/jarvis.stdout.log
data/logs/jarvis.stderr.log

Useful commands:

tail -f data/logs/jarvis.stdout.log
tail -f data/logs/jarvis.stderr.log

Verify the session end-to-end

You have a working first coding session when all of the following are true:

• Jarvis launched the selected runtime from the UI
• the session became visible in chat and in a dedicated session page
• you observed at least one progress update
• you know how to inspect terminal output and backend logs
• you know where to answer if the worker asks for help or reports a blocked state

Next steps

• Use Manage sessions for deeper session operations.
• Read Summary capsules to understand how Jarvis keeps the main chat readable during long tasks.