Frontend shows 'No session selected' while a new worker is still spinning up

[neversettle17-101]

Bug

When a worker agent takes time to spawn, the Electron terminal pane can show:

No session selected. Pick a worker to attach its terminal.

That is misleading when the user has just started a worker. The UI should show that the worker/session is spinning up, and ideally expose which phase is taking time, rather than implying the user failed to select a session.

Source: human report in AO session chat on 2026-07-08
Reported by: @chauhan
Analyzed against: 992e3d01127873eb2ed97b5bd5513f48a4114b23
Verified binary: built from this checkout as /tmp/ao; /tmp/ao status reported daemon ready on port 3001
Area: Electron frontend + daemon session spawn path
Confidence: High for the UI placeholder cause; Medium for the exact slow phase without per-spawn timing instrumentation.
Priority: medium — user-visible confusing state during a common workflow; spawn still eventually succeeds.

Reproduction

1. Open the Electron supervisor for a project.
2. Start a new worker from the UI, e.g. the New task dialog.
3. Use a project/agent where spawn takes noticeable time, such as a worktree-heavy repo or one with provisioning/post-create hooks.
4. Observe the center terminal area while the spawn is still in progress or while the session row exists before its terminal handle has been populated.

Expected

The terminal area should make the pending state explicit, for example:

Starting worker session...
Preparing worktree and terminal.

The UI should not say No session selected when the app knows a spawn is in progress or has a selected session record that is not attachable yet.

Actual

The terminal empty state is keyed only on a missing terminal handle:

• frontend/src/renderer/components/TerminalPane.tsx derives handleId from attachSession?.terminalHandleId.
• If !handleId, it renders the generic empty state: No session selected. Pick a worker to attach its terminal.

That message is correct when there is no selected session, but not correct when a session is selected or a just-started spawn is pending and the terminal handle is not ready yet.

Code Path / Root Cause

The frontend submit path waits on the spawn API before it can navigate to the created worker:

• frontend/src/renderer/components/NewTaskDialog.tsx posts to POST /api/v1/sessions and only calls onCreated(data.session.id) after the response returns.

The backend spawn path is synchronous and does a lot before returning an attachable session:

• backend/internal/session_manager/manager.go creates the durable seed row.
• It creates/materializes the workspace/worktree.
• It runs per-project workspace provisioning hooks.
• It prepares agent-specific workspace files/settings.
• It resolves prompt delivery and launch command.
• It validates the agent binary.
• It creates the runtime terminal/session.
• It calls lifecycle MarkSpawned, which writes the runtime handle metadata.
• For after-start delivery agents, it may also send the prompt before returning.

So spawn can legitimately take time because AO is doing worktree/provisioning/agent/runtime setup inline before the API returns. During that gap, current UI state has no explicit "pending spawn" object to display. If the UI does render a selected session before terminalHandleId is available, TerminalPane treats it exactly like no selected session.

Fix Shape

Small frontend fix:

• Split the terminal empty state into two states:
  • no session: keep No session selected.
  • session exists but no terminalHandleId: show a worker/orchestrator startup message.
• For New task and orchestrator spawn call sites, consider a route/global pending-spawn state so users see "Starting worker..." immediately while the POST is still in flight, before the new session id is known.

Backend observability follow-up:

• Add or surface phase timings around spawn steps (workspace, provision, agent prepare, runtime create, prompt delivery) so the UI or logs can explain why a spawn is slow instead of treating all delay as one opaque POST.

Diagnostics Gathered

/tmp/ao version -> dev
/tmp/ao status -> ready, port 3001, run file ~/.ao/running.json
/tmp/ao session ls -> live agent-orchestrator sessions listed; daemon is current Go rewrite path, not a stale :3000 install

Duplicate search performed in AgentWrapper/agent-orchestrator with these terms:

No session selected spawn
spinning up session selected
New task creates a worker leaves UI previous session
terminal pending spawn
terminalHandleId No session selected
worker spinning up

No exact duplicate found. Nearby issues include terminal focus/blank terminal and generic spawn failures, but they do not cover this misleading pending-spawn placeholder.