A failed Session creation is silent: the Web client shows an empty panel while only the browser console explains why

[luckystation-cmd]

Summary

When a new Session cannot be created — most reachably, because settings.yaml keeps an agent-presets.default that the running build no longer ships — the Web client shows an empty panel reading "Choose a workspace to start" with no explanation. The reason exists only as a console.warn in the browser DevTools. Nothing in the Host log, nothing in the UI.

The Host behavior is deliberate and pinned by a test. The reporting gap is not.

Reproduction

1. A build whose shipped presets are standard, ptc, minimal, cordis.
2. <dsh-home>/settings.yaml carries a default left by an earlier build:

   agent-presets:
     default: code

3. Run dsh web, authenticate, open the GUI.

Observed: the workspace region lists workspaces, the hero renders, and the composer never appears — the placeholder stays on "Choose a workspace to start". The only evidence is:

[console.warning] initial workspace selection failed: SessionCreateError:
session create failed: agent-preset/not-found: agent-presets: preset "code" not
found (available: standard, ptc, minimal, cordis)

dsh-server.log.err is empty, and the initial-selection reconcile sets itself back to waiting and retries on the next snapshot change, so the condition never resolves and nothing is ever shown.

Root cause

Host (deliberate). AgentPresets.resolve refuses an id no configured root supplies — packages/preset/agent-presets/src/index.ts:365. The effective default is the settings-saved value whenever mode selection is on (defaultId / selectionPolicy, packages/preset/agent-presets/src/index.ts:243 and :251), so an upgrade that drops a preset id leaves the setting dangling and every unnamed Session creation fails. packages/preset/agent-presets/tests/settings.spec.ts:165 ("reports an unknown user default only when a session tries to use it") pins this on purpose: the roster is a live directory, so a name absent now may exist by the time a Session asks for it.

Client (the defect). UiWorkspaceService.connectWorkspace — packages/client/ui-workspace/src/client/navigation.ts:144 — is the only place a Session creation runs, and both of its callers reduce a rejection to a console line:

• packages/client/ui-workspace/src/client/navigation.ts:241 — new session failed:
• packages/client/ui-workspace/src/client/navigation.ts:297 — initial workspace selection failed:

Every other error surface in the client is Session-scoped (the composer announces promptError and machine notices as a toast). A failure that happens before any Session exists therefore has no surface that can carry it, which is why the console was the only witness.

Why the obvious host fix is wrong

Making resolve(undefined) fall back to config.default when the saved id is missing would silently substitute a composition the operator did not choose, contradict the contract pinned at settings.spec.ts:165, and be exactly the "silently skip a missing referent" the repository forbids. The defect to fix is the reporting, not the refusal.

Proposal

Announce the failure where the operator is looking, from the one New-Session surface that is mounted whether or not a Session is open. A fix that works on a local checkout:

• UiWorkspaceService publishes its connect outcome as a snapshot source, navigationFailure: HostObservable<{ revision: number; message: string | undefined }>. connectWorkspace reports on the rejection arm and withdraws on the success arm, including the blank-Session reuse path, so a completed connect never leaves an announcement for a surface that mounts later. revision increments per publish so an identical repeated failure announces again instead of being swallowed as an unchanged snapshot.
• WorkspaceBrowser (the sidebar.workspaces occupant) binds it through the inject hooks compartment as useNavigationFailure and renders the primitive Toast with a new navigation.failure dictionary key, keyed by revision. The Host's Error message travels untranslated, matching the policy packages/client/ui-workspace/src/client/locales.ts already states for runtime failure strings.
• The existing console.warn calls stay for developer diagnostics.

The browsing region is chosen over the hero picker because conversation.hero.workspace is mounted only while no Session is open, so a New Session that fails from an open Session would stay silent; a single surface also avoids two identical banners when both are mounted (which is exactly the empty state that reproduces the report).

Acceptance criteria

• A failed Session creation renders the Host's reason in the UI (role="alert"), localized through the navigation.failure key with the wire message passed through.
• A later successful connect, including reuse of an existing blank Session, withdraws the announcement so a surface mounting afterwards does not replay it.
• An identical repeated failure announces again.
• The inject face exposes navigationFailure on the browsing region; the source's snapshot object is stable between changes.
• Unit coverage on both sides: service announce / withdraw / reuse-clear / non-Error rejection / disposer, and the rendered copy plus its retirement.

Workaround for affected users

Point agent-presets.default in <dsh-home>/settings.yaml at a preset the build ships (for the build above: standard), or set modeSelectionEnabled: false so the deployment default applies. Delete the key to fall back to config.default.

Related

A durable remedy for the upgrade case — validating or clearing a settings-saved default that no configured root supplies — belongs to agent-presets and is deliberately out of scope here; this issue is about the dead-end being silent.