# How to tell whether an Oysterun agent is working or idle

Send one safe message from the Sessions page and distinguish available, occupied, working, terminal, and unknown states without duplicate work.

Use this Docs guide to distinguish five states in one Oysterun Session: available, occupied, showing visible progress, terminal, and unknown. You will open a real Session, send one safe message, and choose the next action without accidentally sending the same work twice.

The short rule:

Oysterun's current-provider responding indicator proves that the turn is occupied and not idle. It does not, by itself, prove that Codex or Claude has started or is making useful progress. A missing indicator does not prove idle; check the latest result before sending again. A typing notice from another chat participant is a separate signal and does not prove provider activity.

## Before you start

- Your Oysterun Host is connected.
- Codex or Claude Code is installed and signed in on that Host.
- You have at least one Session that you can open. If the Sessions page is empty, choose **New Session**, select Codex or Claude and a Start Folder, then choose **Start Session**.

**Starting screen:** open Oysterun and choose **Sessions** in the main navigation.

## 1. Open the Session chat

![The same Session header and complete composer are visible in the latest conversation view.](../assets/publication/session-available.png)

Visible checkpoint: the same Session header and complete composer are visible in the latest conversation view, confirming that the Session is available.

1. On the **Sessions** page, choose the Session you want to check.
1. Wait for its chat page to open.
1. Confirm that the message composer is visible at the bottom of the page.

Checkpoint:

the named Session and its composer are visible. This proves that the chat is available to inspect or use; it does not prove that the provider is idle, occupied, or making progress.

## 2. Send one safe test message

1. In the composer, enter: Without using tools, reading files, or changing anything, write five short bullet points about the kinds of software-project questions you can answer.
1. Send the message once.
1. Keep the same chat open while Oysterun accepts the message.

Checkpoint:

your message stays visible in the conversation. If the answer completes before you notice a responding indicator, continue directly to step 5; that is a valid fast completion, so do not resend merely to force the indicator to appear. If Oysterun shows an immediate send error instead, the turn did not start; read that error before trying again.

## 3. Recognize an occupied turn

![The same Session shows one safe test request and the current Codex responding indicator in a complete desktop frame.](../assets/publication/turn-occupied.png)

Visible checkpoint: the safe test request appears exactly once while the current provider responding indicator is visible in the same Session.

After Oysterun accepts the message, the current provider may appear below the conversation as **Codex is typing…**, **Claude is typing…**, or another provider-specific responding indicator. Read this as Oysterun's current-provider state, not as a generic chat participant's typing notice.

- **Indicator visible:** the turn is occupied. It may be accepted, queued, starting, running a tool, awaiting control, or suspected stalled; the indicator alone does not distinguish those conditions. Do not send the same request again.
- **New assistant text or a current Tool result for this request appears while the turn remains occupied:** the turn has produced visible progress. Continue following the original request.
- **Stop response is available:** Oysterun currently offers a way to request interruption. Whether interruption is still accepted is separate from whether the turn is occupied or showing progress.

Do not use typing or a timer as progress proof.

A different participant can produce an ordinary typing notice, and some tools produce no intermediate text. Neither a few seconds of silence nor the provider indicator alone proves useful forward progress.

## 4. Handle a suspicious repeated start

A reconnect can make the same turn appear to start again. A repeated responding indicator or a page reconnect is not a reason to send the message again.

1. Confirm that your original message is still visible in the chat.
1. Do not resend it and do not open a second Session for the same request.
1. Wait for one complete answer, explicit error, or stopped result.
1. If the same request appears to produce two answers, or the visible state keeps returning to responding without a final result, open the original message's **…** menu and choose **Copy Debug Info**.
1. Send that information privately to the person who manages this Host. Do not post it publicly.

Checkpoint:

the original message remains the single request being followed. You either receive one terminal result or preserve one private debug record for the Host manager; you do not create another delivery while investigating.

## 5. Confirm that the turn finished

![The same Session shows the single original request and a complete five-item answer with no responding indicator.](../assets/publication/turn-terminal.png)

Visible checkpoint: the original request remains singular, a complete answer is visible, and the provider responding indicator has cleared.

1. Wait for a complete assistant answer, an explicit error, or a visible stopped/canceled result.
1. Confirm that the responding indicator is no longer visible.
1. Read the final result before deciding what to send next.

Checkpoint:

a complete answer, explicit error, or stopped result is visible and the responding indicator has cleared. The turn is terminal. A normal answer means you may send the next instruction; an error or stopped result means you should correct the stated cause before retrying once.

## 6. Recover when the state is unclear

If there is no current-provider responding indicator and no clear final result, or if the visible signals conflict, do not guess that the Session is idle.

1. Use your browser's **Reload** control once.
1. Read the latest message again.
1. If the page still looks incomplete, return to **Sessions** and reopen the same Session once.
1. If a final result appears, follow it. If the state is still unclear, do not repeat the request. Open the latest committed message's **…** menu, choose **Copy Debug Info**, and send that information privately to the person who manages this Host. If that command is unavailable, preserve what you can see and contact the Host manager without resending.

Safe stop point:

after one reload and one reopen, an unclear state remains unknown. Preserve the request and debug information instead of creating duplicate work.

## Status reference

What you see

What it proves

What to do

The Session opens and its composer is visible

Available:

the chat can be inspected or used; provider activity and idleness are not proved

Read the latest result before sending

Oysterun's current-provider responding indicator is visible

Occupied:

the current turn is not idle; continuous or useful progress is not proved

Do not repeat the request; wait, or use Stop response only if you intend to interrupt

New assistant text or a current Tool result for the same request appears while the turn remains occupied

Visible progress:

this turn has produced a new result since it started

Continue following the original request unless you intend to stop it

A complete answer, explicit error, or stopped/canceled result is visible and the provider indicator has cleared

Terminal:

the turn ended, normally or otherwise

Review the result; send the next instruction after a normal answer, or correct the stated cause before one appropriate retry

No provider indicator and no clear final result, or the visible signals conflict

Unknown:

neither idle nor active work is proved

Reload once, reopen once, then preserve debug info instead of resending