Make custom Codex visible, support isolated stock side-by-side, and streamline upstream upgrades #369

Problem and desired outcome

The operator wants an obvious indication that Codex is modified, an easy way to run official stock Codex side by side, and a low-friction upgrade path as upstream publishes frequently. The current stock CLI launcher can connect to the custom shared daemon, while both report 0.164.0; the CLI version alone does not identify the actual execution backend.

Owner: ecochran76 / primary coordinator. Priority: P1. State: READY for specification and implementation. Related: native port PR359; native recovery #364. This is distinct from workspace recovery #368. WIP: planning only; no daemon switching authorized by this record.

Required behavior

• Show a persistent, human-readable STOCK or MODDED identity in the interactive client, reporting the connected backend as well as client version. Include upstream base, patch/build revision and capability status in a compact inspectable command. Detect mismatched clients/backends rather than trusting a launcher label.
• Offer explicit stock and modded launch commands. Stock must genuinely use an official backend, even while the modified daemon is running. Namespace daemon selection, sockets and mutable runtime state so side-by-side sessions and upgrades cannot silently redirect or replace each other. Make configuration/auth/history sharing choices explicit; never silently copy credentials or rewrite histories.
• Retain an operator-selected default command; show which channel it resolves to. Starting an installed channel should not require enrollment, resource reset or a governor.
• Provide one documented upgrade workflow: resolve an official upstream release; apply the versioned minimal patch set; build an identifiable complete package; run capability acceptance through the installed path; stage without interrupting active sessions; switch at an explicit cutover; retain a known-good rollback. Stock upgrades remain independent.
• Surface upstream availability, custom build lag and patch compatibility failures clearly. A failed rebase/build/test must preserve the active package and must not silently remove custom functionality.
• Keep cache use bounded and make reclaiming disposable build artifacts easy without breaking installed packages.

Acceptance

• Two concurrent disposable sessions prove official versus modified backend executable identity and distinct endpoints/state; stock cannot attach to the modified daemon accidentally.
• Visible build identity survives reconnect/resume and accurately reports client/backend mismatch.
• Installed acceptance exercises scoped MCP reload isolation, durable no-model-turn notices, caller/accounting continuity and orphan-output recovery where applicable; report unsupported capabilities explicitly.
• A staged upgrade failure leaves the running version untouched; a successful switch and rollback preserve supported conversation/resource continuity without silent session migration.
• Document which current shared-daemon acceptance gaps remain open. Do not equate source tests or package identity with complete runtime acceptance.

Verified current surfaces

Installed official CLI help provides --no-daemon (bypasses the shared background server) and --remote (explicit endpoint). The ordinary launcher resolves to the official standalone package while the active managed daemon is the custom orphan-output repair. These are useful primitives, not proof that a complete isolated two-channel product already exists.

Concurrent multi-account requirement

Support multiple authenticated accounts concurrently, independently of the stock/modded build channel. Reuse separate CODEX_HOME namespaces and existing native auth/runtime isolation rather than inventing an account store. Native file credentials and keyring lookup are scoped to Codex home. Explicit remote endpoints must not bypass the selected account namespace.

Launch selection and persistent identity should show account alias plus actual build/backend. Logging in, logging out, upgrading or restarting one account must not change another account's runtime or credentials. Preserve account/namespace in recovery bindings; never substitute another account on resume. Validate at least two simultaneous account namespaces and stock/modded combinations without an external provider experiment. Distinguish namespace tests from actual authenticated-account acceptance.

Reuse codex-profiles and separate discovery from ownership

Operator points to ../codex-profiles as the existing account launcher. Current source defaults and checked-out manifest already isolate session/history/databases per CODEX_HOME, sharing config.toml, skills and rules only. Some README introduction text still describes older shared continuity. The current documented cross-profile concurrency guard is a separate restriction that must be examined and narrowed only after actual runtime/state isolation is validated. Preserve the pre-existing modified profiles.toml.

Reuse profile aliases, home resolution and launch management rather than adding another account selector in Wake. Allow read-only discovery/inspection of session records across operator-selected tenant homes, with exact owning namespace/profile provenance and version-aware readers. Reading another tenant's record does not transfer ownership or select different credentials. Resume normally routes to the original owning tenant/runtime; deliberate cross-account continuation needs a separate explicit transfer/fork contract and must not share mutable databases or silently rewrite original history.

Integrate the selected tenant plus channel into HF-19 recovery bindings (#368). The absence of shared session storage must not make an operator's conversations undiscoverable.

Shared operator configuration

Operator explicitly requests common skills, settings and MCP server definitions across tenants. Keep one canonical shared configuration layer, reused by stock/modded launchers and all tenant homes; do not duplicate settings per account. Reuse codex-profiles existing config.toml/skills/rules sharing where compatible. Permit explicit tenant/channel overrides only where necessary and make effective configuration inspectable. A shared edit should reach subsequent launches across tenants; applying it to already-running clients follows supported explicit refresh behavior and must not silently restart sessions.

Sharing MCP definitions is distinct from sharing authenticated MCP sessions, OAuth token storage or service identity. Honor each connector's supported credential scope; preserve intentionally common operator-scoped connections and clearly identify any tenant-specific authentication requirements. Do not assume an account's Codex login determines its MCP identity or copy credentials to manufacture parity. Keep Codex account auth, mutable history/databases, goals/queues and runtime sockets isolated as required by the concurrency design.

Acceptance includes two concurrent tenant launches resolving the same shared skills/settings/MCP definitions, visible overrides, independently correct Codex account identity, and explicit reporting of connector authentication scope or unsupported stock/modded configuration.

Operator decisions: interview round 1

Approved explicitly by operator response "yes all" on 2026-10-27:

1. A tenant can use the same conversations from stock or modded builds when compatibility checks pass. The same conversation must not be active in both. Unsupported versions explain incompatibility and preserve history. Account isolation does not require duplicating every conversation per channel.
2. Browsing is unified across selected tenant homes. Normal resume routes a conversation to its owning account A. A separate "continue with B" operation creates a linked successor under account B, preserving the original conversation. It is not an implicit credential switch or ownership rewrite.
3. Plain codex launches the modded build with the selected account. An explicit codex-stock command launches official stock. Both visibly show actual account and backend.

These resolve product direction; detailed storage compatibility, active-conversation fencing and installed acceptance remain implementation work. No live launcher/configuration changes have been performed by this interview.

Existing profile authentication defect: prerequisite to acceptance

Operator reports that the last several account switches required reauthentication, defeating profile persistence. Reusing codex-profiles is contingent on repairing and verifying this workflow; existing profile directories alone are not acceptance.

Read-only inspection finds seven profile homes retaining distinct regular auth.json files (contents not printed or modified). Interactive Zsh functions inject the repository profiles.toml, while the standalone codex-profile executable runs the repository Python module without that explicit configuration. This is a verified path difference, not an established cause of reauthentication. No token validity, account-switch correctness or daemon namespace alignment has been proved by those checks.

Add a deterministic launcher-level reproduction and inspect effective profile/home, credential-store identity and actual backend namespace. Preserve credentials; do not trigger account login/logout or token refresh experiments without the required scope. Acceptance must cover A -> B -> A and concurrent A/B without avoidable repeated login, including shell and executable entrypoints. Genuine credential expiry/revocation is surfaced accurately and scoped to the affected account. Do not claim the multi-account feature complete merely because CODEX_HOME changes.

Disposable WSL test environment

Operator authorized starting and setting up existing wsl-test, preserving its contents, plus staging/offloading payloads on primary storage and selectively archiving inactive loads to HDD as needed. Inspected Ubuntu 24.04.5 WSL2 fixture distribution, physically under C:\UbuntuRegularizer\Fixtures\wsl-test\distro. Automount is disabled; Windows interop remains enabled. Existing spec7/backup/recovery fixtures are preserved. A separate private lab run directory with synthetic tenant A/B homes, shared-config, artifacts/results/cache and a manifest has been created under the ubuntu user. No production credentials imported; no authentication tests run yet.

Use fast disposable-home tests and actual pinned-build WSL acceptance. Keep rebuildable caches separate from retained packages/evidence. Archive selected inactive payloads with checksum/provenance manifests and validated restoration before deleting staged copies; verify physical HDD target and capacity rather than infer from drive letter or VHD logical free space. No existing distro reset/unregister, live VHD move or global WSL shutdown is included.

Follow-on health consumer compatibility input

Codex Bots requirement #390 is now filed in the controller planning graph #381/#388/#389. Include its capability in future stock/modded/client/backend compatibility manifests and upgrade acceptance planning: absent/unqualified support remains unknown; once qualified, upgrades/rollback must preserve it or explicitly report incompatibility before activation. Reconcile Bots existing runtime/CLI pins and startup guard before shared runtime changes. This records a follow-on compatibility requirement; it does not retroactively expand approved #371 implementation or authorize activation. Delivery timing remains a #389 decision.