Resuming a session does not restore the provider it was created against

[emal-avala]

Raised by Codex on #518 as a P1. Filing rather than fixing there, because it is not a regression from that PR — the same flaw is on main today.

The problem

Resuming a session restores its model name but not the provider it was created against:

// crates/cli/src/ui/modern/run.rs — and commands/mod.rs:1134 on main
if !data.model.is_empty() {
    st.config.api.model = data.model.clone();
}

QueryEngine::llm stays bound to the provider constructed from the current project's startup config. If the selected session was created with a different API base URL, authentication mode, or wire format, the next turn sends the restored model and conversation to the wrong endpoint.

Consequences, roughly in order of how bad they are:

1. The turn fails — the endpoint does not recognise the model. Noisy, but safe.
2. The turn succeeds against the wrong account. A model name valid on both providers routes the restored conversation — including its full history — to whichever one startup happened to configure. This is the case worth caring about: it is silent, and it exports conversation content across an account boundary the user believed they were switching away from.

Why it is not #518's bug

main already does the identical model-only restore in classic /resume:

• crates/cli/src/commands/mod.rs:1134
• crates/cli/src/commands/mod.rs:5995

The in-TUI session picker makes cross-session resume easy enough to hit routinely, so it raises the exposure — but the defect predates it.

Why it needs its own change

SessionData does not persist provider identity at all today — no base URL, auth mode, or wire format. So this cannot be fixed by reading the session harder; it needs:

1. a persisted provider fingerprint on SessionData (with a migration path for sessions saved without one), and
2. a decision at resume time: rebuild the provider from the session's config, or refuse the resume with a clear reason.

Refusing is likely the right first move — rebuilding a provider mid-session touches auth and credential scoping, and a session whose provider cannot be reconstructed should not silently run against a substitute.

Sessions saved before the fingerprint exists have to be treated as unknown provider, which argues for resuming them only when the destination config matches the current one, or warning explicitly.

Suggested acceptance

• SessionData carries enough to identify the provider it ran under.
• Resuming a session whose provider differs from the destination either rebinds correctly or is refused with a message naming the mismatch.
• A session saved before this field exists resumes without crashing, and does not silently bind to a different provider.
• Tests cover: same provider (resumes), different provider (refused or rebound), missing fingerprint (handled explicitly).

[emal-avala]

Partially addressed on feat/session-picker in e963cca, which closes the unsafe path without closing this issue.

A resume into a project whose config names a different api.base_url or api.auth_mode is now refused at the resume preflight, so a restored conversation can no longer be sent over the source project's connection — to an endpoint the user did not choose, or billed to an account they had switched away from.

That is the conservative half of what this issue asks for. What remains, and why this stays open:

• Restoring the session's own provider still needs a persisted fingerprint on SessionData, plus a migration path for sessions saved without one. Refusing on destination mismatch sidesteps that entirely, because it compares the destination project's config against the running one rather than trying to recover what the session originally used.
• Classic /resume on main is unchanged. commands/mod.rs:1134 and :5995 still do the model-only restore with no refusal, so the same hazard exists outside the TUI picker.

The acceptance criteria in the original description still stand. Rebuilding the provider remains the complete answer; the refusal just means the gap is no longer silently exploitable while that work waits.

[emal-avala]

Scope note from three rounds of trying to do the conservative half on feat/session-picker.

Refusing on credential mismatch is not achievable at the resume preflight. It was implemented, found broken in review, and removed in 8644af8.

The reason is structural rather than a missing case:

• Startup is Config::load → load_inner(_, true), which resolves api_key_helper into api_key.
• The resume preflight is Config::load_policy_from → load_inner(_, false), which deliberately leaves it unresolved, because resolving would execute a command from a project the session may never enter.

So the running config and the destination config are not comparable on credentials. Two projects sharing one helper present a resolved key against None; comparing them refuses every helper-based resume. The converse is equally wrong — when a file or environment key already wins, differing helpers are inactive but still compare unequal.

Consequence for this issue: establishing credential identity requires executing the destination's helper, which is the same work rebuilding the provider needs. There is no cheaper approximation, so the account-level protection lands here or not at all.

What did land, and is not in scope here any more: a resume into a project naming a different api.base_url or api.auth_mode is refused. Those are plain config values on both paths and genuinely comparable, so the "restored conversation sent to a different service" case is closed. What remains for this issue is the account-level case — same endpoint and mode, different credentials — plus rebuilding the provider so a cross-provider resume can succeed rather than merely be refused.

[emal-avala]

Second and final scope note: the endpoint half is not achievable at the preflight either, and the refusal has been reverted in d3a5faf.

My earlier note said credentials could not be compared but endpoints could. That was wrong.

Startup rewrites config.api.base_url from the resolved provider kind:

• --provider defaults to auto
• auto falls through to detect_provider(&config.api.model, &config.api.base_url)
• whenever the resulting ProviderKind has a known default URL, it replaces config.api.base_url

The resume preflight uses Config::load_policy_from, which performs none of that. So the running config holds a resolved endpoint and the destination holds the raw file value, and two identically configured projects compare unequal. This happens with no CLI flags set.

Both halves of a config-comparison refusal are therefore unsound, for the same underlying reason: the running configuration is a resolved artifact and the destination configuration is not. Comparing them requires replaying the resolution — provider selection for the endpoint, helper execution for the credential — which is the work this issue already describes.

Practical consequence for whoever implements this: there is no cheap preflight approximation to land first. The resolution has to happen once, for the destination, and then either rebuild the provider from it or refuse on the resolved values. Attempting the shortcut produced four rounds of false-refusals on feat/session-picker, each looking correct until the next resolution step was noticed.