Desktop: state the acceptance conditions for taking over an existing package runtime and for reusing consent #5443

Area

Desktop app

What are you trying to accomplish?

Ship the desktop app to someone who already runs the proxy from a package manager, and know
before shipping that the handover is safe and repeatable. The runtime-ownership work landed the
mechanism: a durable owner record, a consent generation bound to the exact subject shown to the
user, lock-protected package replacement, and a shell that shells out to the bundled CLI instead
of deciding liveness itself. What is missing is the acceptance side — the set of end-to-end
conditions a release has to satisfy before those mechanisms count as proven.

What prevents this today?

Two gaps, both of them about scope rather than design.

The first is the mixed-version case. When the app attaches to a runtime that an older package
install owns, the dashboard the user sees is served by that older runtime, from its loopback
origin, with its own assets. A dialog fix, a consent surface, or any other change shipped inside
the app's bundled resources does not reach that screen. Nothing today states which of the two
combinations a release must be tested against, so "the window opened" has been standing in for
"the user can actually operate the runtime they are attached to".

The second is the consent lifetime. The ownership record binds a grant to an owner, an install
id, a consent generation and a revision, and refuses a takeover whose subject no longer matches.
The app-side half — what the user is shown when the subject changes, what is stored locally, and
when the app must ask again — is deliberately outside that scope. So there is no statement of
what should happen across a relaunch, a package-manager update or repair, an uninstall and
reinstall, or an explicit handback from the CLI.

What should OpenCodex do?

State both as acceptance conditions a release is measured against.

For the mixed-version case, treat "new app + bundled runtime" and "new app + existing package
runtime" as two distinct configurations. The second one needs a check that the user is told which
runtime is answering and which capabilities that runtime does not have, rather than being shown a
screen whose age they cannot see.

For the consent lifetime, name the transitions and the expected behaviour at each: a relaunch
that finds the same subject reuses the grant without asking; a package-manager update or repair
that preserves the subject does not invalidate it; a changed owner, install id or consent
generation asks again and names what changed; an uninstall or an explicit handback releases the
claim so the next owner starts clean; and an unreadable record is never treated as consent.

Example usage or interface

Not an interface change. The deliverable is a short acceptance list that a release check can
walk, and coverage for the transitions that can be exercised without a GUI.

Alternatives or workarounds

Leave both implicit and rely on per-PR review. That is what produced the current situation, where
each mechanism is individually correct and no single check says the product flow works end to
end.

Additional context

Raised while verifying the installed artifact on a real desktop session rather than from source
review. The mechanisms referenced above are already on the development branch; this issue is
about what has to be true before a release claims them.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.