Repository navigation
investigate(codex): align selected home inspection with native SQLite storage configuration #268
Description
Motivation
Priority: P2 investigation/hardening, initially v1.1.0. Confirm native behavior before treating this as a hotfix or a delivery defect.
The Python CLI inspects the selected home's state_5.sqlite, while its native queue subprocess copies the inherited environment and sets CODEX_HOME. It does not handle inherited CODEX_SQLITE_HOME or root sqlite_home configuration. TS explicitly refuses unsupported configured storage and removes the inherited variable before its queue subprocess.
These repository facts do not establish which supported native Codex versions honor either setting, their precedence, or an actual wrong-target submission. First determine the versioned native storage contract from upstream implementation/documentation and isolated evidence. Do not claim confirmed misrouting or security impact from fake-child tests alone.
Fixed source evidence
- Python saved-thread inspection, discovery, and _queue_codex().
- Python native wake environment.
- TS root storage inspection, queue guard/environment, and fake-child fixtures.
Python baseline: published v1.0.3 / 0d25255; relevant code unchanged on main 817d92a.
Proposed investigation and acceptance criteria
- Establish native version/platform-specific resolution and precedence of
CODEX_HOME, SQLite environment overrides, and config keys. Separate unsupported/ignored settings from effective ones. - Define a consistent inspect/resolve/dry-run/queue contract; account for native wake separately without expanding its supported version matrix. A native subprocess must not silently select different storage from the inspected home.
- Prefer bounded pre-effect refusal for unsupported relocation rather than adding broad relocated-storage support in a patch. Preserve unique live-writer checks and inactive opt-in; do not relax ownership guards.
- Cover inherited environment/case handling, root/nested/escaped TOML keys, malformed or unreadable config, default/explicit/inactive homes, and native-home translation where already supported. Keep config reads bounded and Python 3.9 compatible.
- Use isolated fake-child fixtures for environment behavior and separately identify evidence needed for supported native versions. No ordinary send, live-account data or transcript inspection is implied by filing this issue.
- If a real bounded delivery mismatch is established, re-triage the correction for v1.0.4; if not, document that result rather than manufacture parity with TS.
Relationship and scope
Distinct from #180 (session generation), #183 (SSH host-key identity), #181 (handoff contract), and #263 (unknown-send outcomes). This investigation does not authorize Relay/MCP work, general relocated storage, implementation, deployment or publication.
Existing issues were searched; no storage-resolution investigation duplicate was found. No fresh native routing experiment was performed for this comparison.
Current follow-up scope after v1.1.0 — 2026-10-09
The original proposal above is retained as historical context. User-authorized release accounting keeps this issue OPEN and moves the remaining acceptance work from v1.1.0 to v1.2.0.
Shipped in v1.1.0
Bounded pre-effect refusal for inherited SQLite overrides and inspected root storage configuration is shipped. This is a storage-layout guard, not an attestation of the entire effective native configuration.
Merged implementation: #284. Published release, exact source 8ca77cf31254c8287a2593fe484bb30a7dba2727; integrated main CI and PyPI publication/verification succeeded. Publication does not establish operational rollout or new live-agent acceptance.
Remaining acceptance — not completed by the release
- Establish an authoritative, body-free effective-storage contract for supported native Codex versions, including profile/project/system/managed configuration layers and already-running shared servers.
- Validate storage selection and precedence on the relevant native platforms separately from fake-child/environment tests; distinguish ignored settings from effective settings.
- Define consistent inspection/dry-run/queue behavior with configuration changes between checks, preserving fail-closed ownership and inactive-home guards.
- Do not claim confirmed misrouting, a security exploit, relocated-storage support or an expanded wake-version matrix without the necessary evidence.
This is backlog/state accounting only. No new runtime implementation, skill merge/release, operational change, native experiment or publication is authorized by this reassignment.
Activity
abruption commentedon Oct 14, 2026
Owner-authorized work allocation (2026-10-15; correlation PY120-ISSUE-DELEGATION-20261015): request submitted to the session-peer-claude implementation session; consumption/acceptance is not yet confirmed.
First: investigate and implement bounded, evidence-backed effective-storage/original-server hardening and offline regression fixtures. Keep published storage refusal intact and distinguish disk config from the existing owner's effective storage.
Use a separate isolated worktree based on current origin/main and report frozen commits with tests and remaining acceptance gates. Shared files are edited sequentially. The coordinating Codex session will run independent-cli-review with separate non-interactive Claude Opus 5.5 and Codex CLI reviewers, address findings, and then create the PR. No implementation PR has been created yet. No merge, release, operations change or expanded live test is authorized by this allocation. Target milestone date remains 2026-10-18; unproven safety requirements will not be weakened to meet it.
abruption commentedon Oct 14, 2026
Independent CLI review of frozen 488c9de is complete. Before PR creation, implementation follow-up was requested for Windows fixture PWD expectations, dry-run/cwd documentation, storage refusal before wake-rate reservation, translated WSL/native-Windows coverage, and daemon compatibility/source-evidence limits. Reviewer suggestions are checked against source rather than automatically adopted; root profile-v2 activation assumptions remain source-dependent. No live/platform validation or merge is implied. A revised frozen candidate and independent follow-up review are required; no #268 PR has been created yet.
abruption commentedon Oct 14, 2026
Owner policy decision: use option 3 as the default compatibility policy. Remove blanket send/dry-run refusal based solely on a daemon control-socket entry or connectivity; preserve existing SQLite override, writer-ownership and explicit inactive-home guards while strengthening only verifiable bounded checks. Do not claim effective/startup SQLite identity or atomic storage agreement. initialize can report server home, but the reviewed initialize/config/read/queue contracts do not attest startup-captured SQLite identity. WSL-to-native-Windows remains a separate, explicitly unverified storage-validation scope rather than blanket WSL rejection. Dry-run checks the same planned execution boundary without effect; subsequent send still rechecks and has a time-of-check gap. No new strict mode, native daemon probe, --no-daemon workaround or runtime metadata field is authorized in this change. Revised frozen code and independent CLI re-review are required before PR creation. Issue remains OPEN for full effective-storage and native platform acceptance; no merge/release/operations authorization.
abruption commentedon Oct 22, 2026
Research results — 2026-10-22
The research-first follow-up measured ten additional native storage conditions on each of macOS arm64 and Linux aarch64 using Codex 0.163.0. All 20 final conditions agreed with the expected storage selection, and the config-read fields were separately checked. The existing guard shipped through #311 remains unchanged; this work does not complete #268 or widen supported storage layouts.
Findings
config/readwithout cwd reports the user-config directory. Including the process cwd reports the project layer in these fresh fixtures.--profile research app-serverexited 1 before initialization and created no state DB. This does not test positive profile storage on commands that support profile selection.These observations strengthen the distinction between inspecting current configuration and identifying the persistence domain actually held by a running process. Supplying cwd does not fix the earlier A-to-B live-config case where the server retained A while readback changed to B. Process file handles are laboratory evidence, not a portable production attestation API.
Evidence and limits
Native source:
83086188ae0614bd882818ff1aa23f3194962012(0.163.0). The test processes used private homes/configurations and OS network restrictions. No thread, queue or model-turn request was issued. Host system configurations were absent and the Mac forced-preference check was negative. Shared-daemon reuse, real queue routing, owner replacement, actual MDM/cloud settings and Windows remain unverified.The source-only main comparison advanced to
342ed69a174c206c1de52a59491b131e0753cfa5; the required storage identity, original incarnation and expected-empty contracts were not added in the reviewed paths. Main was not built or executed.The reproduction harness, sanitized results and report are preserved in local research commit
77b60b4e96c9e9388f94b00c96ce4ede621e08d6(not yet pushed or released). Python compilation, generated standalone verification and 65 documentation tests passed. Independent read-only review found no blocking issue in the stated conclusions; the scripts remain research harnesses with documented cleanup/output limitations.Follow-up
The public upstream contract question is openai/codex#55768. Keep the existing compatibility policy: no daemon-socket-only refusal, no inference of live storage agreement from a successful check, and no automatic resend after uncertainty. These measurements do not justify expanding the macOS preference version allowlist or marking this issue complete.