Record and restore non-secret code launch recipes per OMP session

[atyrode]

Context

Parent: #5

code can make persisted OMP sessions discoverable and repository-aware, but an OMP session does not necessarily preserve every launch-time choice owned by code. Generated routing is currently passed as a temporary one-shot --config; authentication vault selection, launch mode, generator facets, and the managed-config revision are also launcher context rather than transcript content.

Session replay and launch-recipe restoration are different contracts:

• OMP owns conversation/session replay, including session-owned model and thinking changes;
• code owns the non-secret recipe used to launch that session;
• current managed security policy must always win over historical launch metadata.

Goal

Record a versioned, non-secret launch receipt for future trusted sessions and let code explicitly resume with either the current setup or a compatible recorded recipe. Existing sessions without receipts must remain fully resumable.

Phase 0: verify the supported OMP lifecycle

Before choosing storage or hooks, verify the pinned OMP build's supported way to learn the final session ID and trusted state root after session creation. Prefer a documented hook, extension event, RPC/API, or lifecycle contract. Do not scrape terminal output or infer the newest file by timing.

Record:

• when the full session ID becomes authoritative;
• whether a resumed/forked session changes identity;
• how profile and explicit --session-dir roots are exposed;
• whether syscall.Exec must be replaced or supplemented to write a receipt safely;
• failure semantics when OMP exits before creating a session;
• startup precedence among a generated config's default model, the session's last active model/thinking state, and an explicit --model/thinking override.

Pinned v17 source already establishes the baseline to reproduce in a focused wrapper test: createAgentSession restores session model state only when no explicit model/model pattern is supplied, and its startup-resume tests intentionally restore the last active role model. A generated one-shot --config that changes the default role does not by itself express an explicit model override. Treat the reported behavior as a code resume/customization precedence gap unless the focused experiment disproves that argv/config path; do not classify normal OMP session replay as corrupted state.

Identity and storage invariant

A receipt is keyed by the tuple (canonical trusted state root, full session ID), never by session ID or prefix alone. A receipt resolved from one state root must never influence a resume in another root.

Requirements:

• only a fully resolved session may load a receipt;
• ID prefixes are resolved by Make code session discovery repository-aware and resume state roots explicitly #5 before any receipt lookup;
• duplicate prefixes across roots fail deterministically;
• the receipt's embedded root and ID must match its lookup key;
• moved, missing, malformed, mismatched, or unsupported receipts degrade safely to current-setup resume;
• untrusted ompu roots never participate.

Store receipts under an XDG state directory owned by the user. The directory must be private (0700), receipt files private (0600), symlink traversal rejected, and writes atomic (private temporary file plus rename in the same directory). Partial or concurrent writes must never produce a trusted recipe.

Receipt data boundary

A versioned receipt may contain stable, structured references such as:

• canonical trusted state-root identity and full session ID;
• recorded cwd/repository identity;
• managed versus generated launch mode;
• generator facet/preset selection;
• OMP profile or explicit session-root selector;
• a non-secret stable vault reference (vaultRef) resolved through the live manifest; never a copied provider identity or email;
• managed configuration revision/schema version.

It must never contain:

• bearer tokens, OAuth material, API keys, cookies, or broker secrets;
• prompts, transcript bodies, tool output, or generated system prompts;
• arbitrary environment variables;
• copied historical approval, tool, isolation, or security policy;
• an opaque generated config blob when structured stable selections exist.

Resume UX

Offer two explicit actions:

1. Resume with current setup (default): current vault and current Nix-managed configuration, while preserving the session's compatible active model/thinking state unless the user explicitly overrides it.
2. Restore recorded setup: re-evaluate compatible recorded generator/launch choices against the current managed configuration.
3. Resume with explicit customization: the generator profile/default model and any explicit forwarded model/thinking flags selected for this resume override the session's previous active model/thinking state.

The precedence contract is:

1. current managed security policy and wrapper restrictions;
2. explicit resume customization or explicit CLI model/thinking flags;
3. compatible session-owned active model/thinking state;
4. current compatible defaults and fallbacks.

Merely focusing a profile or displaying its defaults is not intent. Entering the explicit customize flow and confirming its launch is. The wrapper must translate that confirmation into supported OMP launch arguments rather than expecting a one-shot config default to override replayed session state.

Authentication identity must never switch silently. If the recorded vault differs from the active vault, show both provider/account combinations and require an explicit choice. Record only the vault ID; resolve its current redacted identity through the live vault manifest.

The launch target must remain explicit throughout customization:

• selecting a history session establishes a pending resume target;
• entering generator customization preserves that target until the user clears or replaces it;
• the launch summary/button says Resume, not Launch new, and includes the session title plus unambiguous ID suffix;
• focusing or hovering another history row does not change the pending target; all selection and resume/customize actions remain keyboard accessible;
• returning to a new-session launch requires an explicit clear action.

Compatibility

• Validate recorded facets and identifiers against the current catalog/configuration.
• Never resurrect historical managed security policy.
• Explain removed or renamed choices and allow current-setup resume.
• Schema upgrades must be versioned and deterministic.
• Missing receipts for pre-feature sessions are expected, not errors.
• A receipt is optional metadata and must never become necessary to resume the underlying OMP session.

Acceptance criteria

• The pinned OMP lifecycle for obtaining authoritative session ID/root is documented and covered by a focused experiment.
• Receipts are keyed by (canonical trusted state root, full session ID) and prefixes never select receipts.
• Cross-root, duplicate-prefix, mismatched-receipt, symlink, permission, partial-write, and concurrent-write cases have focused tests.
• Receipt storage is owner-private and atomic.
• Receipts contain no credentials, transcript content, prompts, arbitrary environment, or historical security policy.
• Existing sessions without receipts remain discoverable and resumable.
• Current-setup resume is the default.
• Restoring a recorded vault requires explicit confirmation when it differs from the active vault.
• Recorded choices are validated against the current managed configuration with actionable incompatibility messages.
• A focused pinned-OMP test reproduces and documents startup precedence for session-restored model/thinking, generated config defaults, and explicit model/thinking flags.
• Resume with no explicit customization preserves compatible session-owned model/thinking state.
• Confirmed resume customization translates the selected profile/default model into an explicit supported override that wins over the previous session model.
• Explicit forwarded --model/thinking flags win during resume; incompatible vault/model combinations stop for an actionable choice without silently changing identity.
• Customization preserves the selected resume target until explicitly cleared or replaced.
• The final action unambiguously distinguishes Launch new from Resume <title> · <ID>.
• Untrusted sessions remain isolated and never read or write trusted receipts.

Likely ownership

• pkgs/code-tui/
• pkgs/omp-configured/default.nix
• pkgs/omp-configured/README.md
• focused state/permission and launch-argv tests