Session spawned without explicit --harness stores empty agent; UI mislabels it as codex

[codebanditssss]

Bug

A worker/orchestrator spawned without an explicit --harness runs the daemon's default agent (claude-code) but its stored harness is empty, so the API omits it and the UI mislabels the agent. Observed live: a session running Claude Code showed Agent: codex in the inspector.

Analyzed against: 3e64c15 | Confidence: High

Reproduction

1. Spawn a worker with no explicit agent (UI New-worker default, or ao spawn --project p --prompt x).
2. The terminal boots Claude Code.
3. The inspector's Overview shows Agent: codex, and GET /api/v1/sessions returns the session with no harness field.

Root Cause

• effectiveHarness("", kind, cfg) (backend/internal/session_manager/manager.go) returns "" when nothing is explicitly set and there's no role override.
• seedRecord persists Harness: cfg.Harness → empty.
• The agent that actually runs is resolved later: agentRegistry.Agent("") (backend/internal/daemon/lifecycle_wiring.go:158) falls back to the daemon's defaultHarness (AO_AGENT, default claude-code) — but that resolution is internal and never captured back onto the record.
• The session DTO (domain.SessionRecord.Harness, json:"harness,omitempty") is therefore empty → omitted from JSON → the frontend's toAgentProvider(undefined) defaults to "codex" (frontend/src/renderer/types/workspace.ts).

So the backend's empty→default resolution and the frontend's undefined→codex default both diverge from the agent that's actually running.

Fix

Resolve the harness to the daemon's configured default before persisting the seed record, so the stored/returned harness matches the agent that runs. Inject the same default the resolver uses (AO_AGENT / config.DefaultAgent) into the session manager.

Impact

Every session spawned without an explicit agent is mislabeled in the UI (and the API can't report the real agent). Labels: bug, priority: medium.