Browser: distinguish requested model keys from verified picker labels

[DragonFSKY]

Summary

Browser-mode CLI output currently uses the requested/internal model key in places that read as though they describe the model active in ChatGPT. These values can differ because browser aliases are mapped to picker labels and because current/ignore strategies do not necessarily select the requested target.

GPT-5.6 makes the distinction especially visible:

• gpt-5.6 currently targets the GPT-5.6 Sol picker entry.
• gpt-5.5-pro and older Pro aliases target ChatGPT's generic Pro entry.
• A verified bare Pro picker result proves the selected tier, but not a server-side GPT version, so it must not be expanded to GPT-5.6 Pro.

Current behavior

For example:

oracle --engine browser --model gpt-5.6 --dry-run summary \
  -p "Reply exactly MODEL_DISPLAY_SMOKE_OK."

The launch summary identifies the run only as gpt-5.6. Completed-session summaries and status rows likewise use metadata.model, even when persisted model-selection evidence contains a different verified resolvedLabel.

This is also misleading with --browser-model-strategy current: the current picker label may differ from the requested key, while the compact completion summary still prints the requested key.

Expected behavior

• Before browser selection, label the values as a target and requested key rather than presenting either as observed fact; for example, target=GPT-5.6 Sol; requested=gpt-5.6.
• Persist and print the internal key alongside the existing picker evidence.
• After selection, use the exact resolvedLabel in session/status/completion displays only when verified=yes.
• Keep the requested/internal key when evidence is absent or unverified.
• Never infer a concrete GPT version from the generic Pro picker label.

Scope

This is a display/provenance issue, not a GPT-5.6 picker-selection failure. API-mode output should remain unchanged.

Observed on current main at 575e0881ca28beb76db6460a84a28405aaedb117 after #314.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 2, 2026, 12:20 PM ET / 16:20 UTC.

Summary
This issue remains necessary: current main persists picker evidence but still renders the raw session model key in status and TUI displays, while browser selection can mark a configured target as resolved when no observed label exists. The open linked implementation at #318 owns this exact repair, so this issue should remain open until that branch is rebased, reviewed, and merged.

Likely related people: Peter Steinberger (medium confidence, current-main and baseline history) and Rokurolize (medium confidence, recent browser-session display work).

Reproducibility: yes. —current source provides a high-confidence reproduction path: create browser metadata with a verified resolvedLabel different from metadata.model; status and TUI render the raw key, while explicit selection can also substitute an unobserved target as resolved. No live browser execution was needed for this source-proven defect.

Next step
An open linked implementation already owns this bounded repair; the immediate next action is to rebase and review #318 rather than open a duplicate fix branch.

Review details

Best possible solution:

Rebase and land a focused display-layer repair that persists requested key and target separately, uses an exact observed label only when it is verified, and preserves raw model keys for all operational behavior.

Do we have a high-confidence way to reproduce the issue?

Yes—current source provides a high-confidence reproduction path: create browser metadata with a verified resolvedLabel different from metadata.model; status and TUI render the raw key, while explicit selection can also substitute an unobserved target as resolved. No live browser execution was needed for this source-proven defect.

Is this the best way to solve the issue?

Yes—the linked approach is the narrowest maintainable solution when it keeps display provenance separate from routing: only verified observed labels should replace the requested key in presentation, and generic picker labels must remain literal.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked implementation at fix(browser): report verified model labels in CLI output #318 is reported as merge-conflicted in the supplied context, so it needs a current-main rebase and regression check before landing.
• The repair must not let a picker target or generic Pro label imply an unobserved server-side GPT version, and must retain raw keys for filtering, routing, and log lookup.

Codex review notes: model internal, reasoning high; reviewed against 3942429f5d9b.

Label changes

Label justifications:

• P2: This is a bounded correctness issue in browser-session output with a clear but limited user impact.
• impact:ux-friction: Browser users can be misled about the selected model even though the run itself can still complete.

Evidence reviewed

What I checked:

• Status table still uses the raw session key: The status-row formatter uses meta.model directly and does not consult browser.modelSelection.resolvedLabel, so a verified browser picker label cannot appear in the compact status output. (src/cli/sessionTable.ts:37, 3942429f5d9b)
• TUI still presents raw model fields: The TUI session header and per-model rows print meta.model and run.model directly, independently of persisted browser selection evidence. (src/cli/tui/index.ts:307, 3942429f5d9b)
• Selection evidence can substitute the target for an absent observation: For explicit selection, the browser selector assigns desiredModel when no observed picker label exists, then marks the evidence verified when strategy is not current; this is the provenance ambiguity described in the report. (src/browser/actions/modelSelection.ts:69, 3942429f5d9b)
• Detailed evidence lacks a separate target/key contract: The detailed session formatter prints only requested and resolved fields from existing browser evidence, so it cannot preserve the requested key, selection target, and verified observed label as separate values. (src/cli/sessionDisplay.ts:739, 3942429f5d9b)
• Current regression coverage confirms the relevant current-strategy distinction: Existing tests show a current-picker label can differ from the requested key and remain unverified, supporting the need for verified-only display behavior; no current source path reconciles that evidence into compact output. (tests/browser/modelSelection.test.ts:1380, 3942429f5d9b)
• Current-main provenance: Current main is commit 3942429f5d9b2e129dee9ef4fa46f943fe2050a8 from August 2, 2026; the latest shipped release v0.16.1 is an ancestor of current main, and the relevant display paths have not gained this fix since that release. (src/cli/sessionTable.ts:37, 3942429f5d9b)

Likely related people:

• Peter Steinberger: Current-main history identifies Peter Steinberger as the merger of the current head, and blame traces the raw status-table rendering to the available repository baseline commit. (role: current-main and baseline contributor; confidence: medium; commits: 3942429f5d9b, 5daa6ce8c352; files: src/cli/sessionTable.ts, src/browser/sessionRunner.ts)
• Rokurolize: Recent history shows Rokurolize updated browser-session display behavior related to preserved Pro capture, adjacent to the persisted browser evidence surface. (role: recent browser-session display contributor; confidence: medium; commits: 3f9db037ef6d; files: src/cli/sessionDisplay.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[DragonFSKY]

Implementation contract confirmed before updating the candidate PR:

• requestedKey is Oracle's persisted model key.
• target is the label intended for picker selection.
• resolvedLabel is used as the effective display value only when it is non-empty and verified=true.
• The exact picker label Pro remains Pro and does not prove a concrete server-side GPT version.
• Before selection, select reports target plus requested key; current and ignore report their picker strategy plus requested key.
• Compact status uses a verified label, otherwise the requested key. Detailed views retain both when they differ.
• gpt-5.6 and gpt-5.6-sol currently share the GPT-5.6 Sol target but retain distinct requested keys.
• Legacy sessions, custom labels, unverified evidence, and non-primary model runs fail closed to the requested key.
• API display/routing, model mapping, persisted schema, and product/help wording are out of scope.

Draft PR #318 has been updated to cover CLI and TUI paths, with real persisted-browser replay evidence and focused/full-suite validation.