Session started but produced no output

The session's Claude Code process started but never said anything before the time limit, so Omniscio stopped it. Send a message to try again first — usually the second start works. If it keeps happening, work down the checks below; the message itself now names the engine, model, account and a reference.

What it is

When a session is started and the underlying CLI produces no output at all within the first-output window, the watchdog writes one line into the conversation:

Session timed out — Claude Code produced no output after N seconds, so it was stopped. The CLI may be hung or failed to start. (engine …, model …, account …, reference …) Send a message to try again.

The same watchdog also hands back the "thinking forever" case — a CLI that is alive but silent while its transcript file stays warm — with the same disposition. Everything below applies to both.

The line carries four facts on purpose, so a single screenshot is enough to start a diagnosis:

engine — which provider the session was launched on (anthropic for native Claude Code, or a vendor id such as a DeepSeek/GLM/Kimi route).
model — the exact model id the spawn resolved to.
account — the first characters of the Claude account (or supply row) the session was started under. none means it ran on no account — a managed/keyless spawn or a vendor route.
reference — the first characters of the session id, which matches the app log.

Where to find it

The line appears in the session's own conversation in the Projects sidebar: when the watchdog stops the session, it writes the timeout as the last message in that timeline. The settings the checks below point at are all in the app's Settings — Connected Tools and Claude CLI Location for the CLI, and AI Providers for a vendor route's key and balance.

How it behaves

What Omniscio already tried

Before the line appears, the watchdog has already been patient: it extends the first-output window while the whole machine is saturated, gives an alive CLI extra patience while the box is still busy (bounded, so a genuinely wedged CLI still surfaces), and counts transcripts that are still being written as activity. Only after all of that does it stop the session and write the line.

Checks, in the order that fixes it

Try again once. Send the session a message. A one-off slow start (a cold cache, a network blip) clears this way and needs nothing else.
Is the computer under heavy load? If the fans are loud and everything feels slow, the session was starved, not hung. Follow Computer feels slow? — the load, not the session, is the thing to fix.
Is the CLI installed and reachable? A binary that went missing or was moved produces the dedicated line Claude Code isn't installed (or can't be found) instead; if you are seeing this timeout after a reinstall or a move, check Settings → Connected Tools and Settings → General → Claude CLI Location. Details: First-time setup.
Can that account start a session? A signed-out, capped or disabled account can start a process that never gets an answer. Check the account named in the message: Auth pathways and the pool's exhaustion card in Account Pool. Omniscio normally re-signs an expired account in without you — Sign accounts back in automatically.
Is that engine/model healthy? If engine names a vendor route rather than anthropic, the vendor's endpoint key or balance is the suspect: API Keys, and the provider's row in Settings → AI Providers.
Is the disk full? A full data drive can stop the CLI before it writes anything. Computer feels slow? ends with the free-space check.

If none of that helps

Open the app log and keep the two facts the message gave you together: the reference and the engine/model/account triple. Then file it — a session can file it for you with the diagnostic detail attached: Bug Report Intake. Support needs exactly those four values plus roughly when it happened; the log does the rest.