Sync fork to latest OpenAI Codex upstream baseline

[ARCJ137442]

Background

The Exomind fork should track a clear and current upstream baseline from openai/codex.

Current Git-state snapshot:

• Fork repo: exomind-team/codex
• Fork main: 153dab6d4
• Current working branch: fix/issue-30-queue-retry-ordering
• Merge-base between fork branch lineage and upstream/main: b6d43ec8eb38738c648acc20aeccd1080d9d5381
• That merge-base is feat: status line with real data (#13619) from 2026-03-06
• Fork main is currently behind upstream/main by 42 commits and has 22 fork-only commits

This means the fork is neither a clean rust-v0.111.0 release baseline nor current upstream/main. We need a dedicated tracking issue for synchronizing to the latest Codex baseline before defining the Exomind release line.

Goals

• Sync the fork to the latest practical upstream Codex baseline
• Preserve Exomind-specific features and fixes during conflict resolution
• Establish an explicit versioning strategy for Exomind releases after sync
• Record the final upstream baseline commit/tag in repository docs/issues for context persistence

Proposed Task List

• Inventory fork-only commits on main and active feature branches
• Compare upstream/main vs latest stable upstream release notes and decide merge target
• Merge latest upstream changes into fork main
• Resolve conflicts without regressing Exomind queue/steer/repeating-message features
• Run CI and local Windows build verification after sync
• Decide and document Exomind version-line format
• Update release workflow if custom Exomind version suffixes are needed
• Record the synced upstream commit/tag/hash in README and issue/PR history

Acceptance Criteria

• Fork main is updated to a clearly identified latest upstream baseline
• Exomind custom features still work after sync
• CI passes after the merge
• A Windows codex.exe test build is produced and validated
• Exomind versioning plan is documented and actionable

Notes

If we keep a custom version suffix such as -exomind, the current Rust release workflow regex will need adjustment because it currently only accepts stable, -alpha.*, or -beta.* suffixes.

[ARCJ137442]

Kickoff update:

• Started sync work on local branch: chore/sync-latest-openai-main
• Base branch: main (153dab6d4)
• Next step: merge upstream/main into the sync branch and inventory the real conflict surface
• Immediate focus: preserve Exomind queue/steer/repeating-message behavior while moving the fork baseline forward

I will use this issue as the external task ledger while the sync branch is in progress.

[ARCJ137442]

Sync progress update:

• Created and pushed branch: chore/sync-latest-openai-main
• Merge commit: 373626ddf1c318b8383037ce9055dd41e1ec8347
• Action taken: merged upstream/main into the sync branch

Observed result:

• The merge completed without textual conflicts
• One compatibility compile break surfaced in codex-rs/tui/src/chatwidget/tests.rs
• Cause: upstream-added UserMessage initializer did not include Exomind fork fields (repeat_mode, steer_mode, enqueue_seq)
• Fix applied directly in the sync branch before committing the merge

Validation completed so far:

• Targeted Exomind TUI feature tests passed:
  • shift_tab
  • alt_up
  • pending_input_preview
• Full cargo test -p codex-tui passed
• Build/test target dir used: G:\cargo-target-sync-upstream

Current branch state:

• Branch is now on GitHub and ready for follow-up validation / PR work
• Next steps are broader validation, release/version-line decisions, and any additional compatibility fixes surfaced outside the TUI crate

[ARCJ137442]

Local validation update on chore/sync-latest-openai-main:

Completed locally after the upstream merge checkpoint:

• cargo fmt --all --check
• cargo test -p codex-tui
• cargo test -p codex-cli
• cargo build --bin codex
• runtime smoke check: G:\cargo-target-sync-upstream\debug\codex.exe --version

Results:

• All above commands passed
• Built binary path: G:\cargo-target-sync-upstream\debug\codex.exe
• Reported version from the built binary is still codex-cli 0.0.0

Interpretation:

• The upstream sync branch is locally buildable and testable after merge
• The remaining versioning work is now clearly separated from the sync itself
• Next work should focus on version-line design / manifest updates / release workflow compatibility

[ARCJ137442]

Opened PR for the upstream sync checkpoint:

• PR: chore: sync fork with latest OpenAI Codex upstream #33
• Link: chore: sync fork with latest OpenAI Codex upstream #33

The PR body records:

• upstream merge scope
• the one compatibility fix needed after merge
• local validation evidence
• the fact that version-line work remains follow-up scope after the sync checkpoint

[ARCJ137442]

CI follow-up update:\n\n- Identified the failing
ust-ci / Fork smoke (clippy + tests) case from run 22798470692: codex-app-server-protocol::schema_fixtures::schema_fixtures_match_generated.\n- Root cause: after the upstream merge, our fork's vendored app-server schema fixtures were stale relative to the current generated output for the command/exec protocol surface.\n- Fix pushed in 63ffdd2 ( est: refresh app-server schema fixtures).\n- Scope of the fix: 11 schema fixture files only (7 TypeScript fixtures, 4 JSON fixture files).\n- Relevant local validation passed:\n - cargo test -p codex-app-server-protocol schema_fixtures_match_generated -- --nocapture\n - cargo test -p codex-tui\n- I also ran a full Windows cargo nextest run --all-features --no-fail-fast --cargo-profile ci-test; it still shows pre-existing/unrelated Windows-local failures/timeouts outside this schema-fixture scope. The original Linux CI failure we are fixing here is addressed by the schema refresh.\n\nNext step: watch PR #33 until GitHub CI turns green, and rework if any new failure appears.

[ARCJ137442]

Final status update for this sync checkpoint:\n\n- PR #33 is now green.\n-
ust-ci / Fork smoke (clippy + tests) passed on the updated commit 63ffdd2.\n- CI results (required) is also green.\n- PR merge state is now CLEAN.\n\nThis resolves the post-sync CI break that was blocking the upstream-sync checkpoint.

[ARCJ137442]

Post-CI sync recheck:\n\n- PR #33 is CI-green, but it is no longer exactly at the latest openai/codex main tip as of this recheck.\n- After fetching upstream, current latest upstream commit is cf143bf (eat: simplify DB further (openai#13771)).\n- The sync branch chore/sync-latest-openai-main is based on upstream commit 5ceff65 (safety: honor filesystem policy carveouts in apply_patch (openai#13445)) and is now behind upstream by 1 commit.\n- Divergence after fetch: HEAD...upstream/main = 24 left / 1 right.\n\nSo the checkpoint PR is valid and green, but if we require strictly latest upstream head, we need one more incremental sync pass.

[ARCJ137442]

Incremental sync update after strict-latest recheck:\n\n- Upstream advanced twice while we were validating, so I did two additional incremental sync merges on the existing PR branch.\n- Current branch head pushed: �a0a46665.\n- Current upstream main tip at push time: e84ee33 (Add guardian approval MVP (openai#13692)).\n- Immediate pre-push recheck confirmed the branch was aligned with upstream latest at that moment.\n\nLocal validation was kept intentionally narrow to avoid a full rebuild/test cycle, but it covered both upstream-added surfaces and fork-sensitive areas:\n- First incremental sync validation:\n - cargo fmt --all --check\n - targeted codex-state, codex-core, codex-cli, codex-app-server filters for memories/rollout/thread/debug-clear-memories\n- Second incremental sync validation after guardian landed:\n - cargo fmt --all --check\n - cargo test -p codex-core guardian\n - cargo test -p codex-tui guardian_approval\n\nNext step: watch the refreshed PR CI, then do one more strict upstream recheck before merging.

[ARCJ137442]

Follow-up on the remaining PR #33 fork-smoke failure.

Pushed fix commit: 7145abb5c19c0c466a5b8c5cbcb1be1512613f02

Root causes:

• guardian_allows_shell_additional_permissions_requests_past_policy_validation updated sandbox_policy to DangerFullAccess but did not refresh the derived file_system_sandbox_policy and network_sandbox_policy. On Linux CI that still selected the platform sandbox path and failed with LandlockSandboxExecutableNotProvided.
• guardian_review_request_layout is platform-sensitive in practice: Windows and Linux serialize the embedded planned-action JSON in different field orders.
• experimental_popup_includes_guardian_approval is also platform-sensitive: Linux inserts the experimental Bubblewrap sandbox line into the popup.

Fix applied:

• Synced the derived sandbox policies in the guardian shell test so it actually exercises the intended DangerFullAccess path.
• Added Linux-specific insta snapshots for the guardian request layout and the experimental popup while preserving the existing default snapshots for Windows/non-Linux.

Targeted validation completed with G:\cargo-target-sync-upstream:

• cargo fmt --all --check
• cargo test -p codex-core 'codex::tests::guardian_tests::guardian_allows_shell_additional_permissions_requests_past_policy_validation' -- --exact
• cargo test -p codex-core 'guardian::tests::guardian_review_request_layout_matches_model_visible_request_snapshot' -- --exact
• cargo test -p codex-tui 'chatwidget::tests::experimental_popup_includes_guardian_approval' -- --exact

Next gate remains unchanged: wait for CI to go green, then do one more strict fetch/recheck against latest upstream/main before merging.

[ARCJ137442]

Second follow-up on PR #33.

The previous CI rerun removed the guardian logic failures and left one remaining Linux-only snapshot mismatch in experimental_popup_includes_guardian_approval@linux: the selected-row marker was ?, not >.

Pushed snapshot-only fix: 99efbf1fb8362177fe2d3e51a3830da8306e7dd7

No code-path change in this delta; it is only the Linux snapshot text correction from the CI diff.

[ARCJ137442]

Latest CI failure is no longer in the guardian/snapshot area.

Current failed run: 22802014604

Remaining red tests in fork-smoke:

• suite::realtime_conversation::conversation_startup_context_falls_back_to_workspace_map
• suite::realtime_conversation::conversation_start_injects_startup_context_from_thread_history

Both are timing out waiting for events in the realtime conversation test harness. I ran the exact two tests locally against the same branch/HEAD and both passed:

• cargo test -p codex-core --test all 'suite::realtime_conversation::conversation_startup_context_falls_back_to_workspace_map' -- --exact
• cargo test -p codex-core --test all 'suite::realtime_conversation::conversation_start_injects_startup_context_from_thread_history' -- --exact

So the current blocker looks like an upstream/main CI flake rather than a deterministic regression from our sync branch changes. I am rerunning the failed workflow instead of changing code blindly.

[ARCJ137442]

Final merge gate check passed.

Current PR head: 99efbf1fb8362177fe2d3e51a3830da8306e7dd7
Current upstream/main: e84ee33cc02e693a3cf66204c72cb37e8dda3ed6
merge-base(HEAD, upstream/main) = e84ee33cc02e693a3cf66204c72cb37e8dda3ed6

That means the branch still contains the latest upstream/main after CI finished, and required CI is green. PR #33 is now merge-eligible.

[ARCJ137442]

Versioning decision for Exomind fork releases:

• Canonical fork version format: OpenAI-version-exomind
• Goal:
  • visibly distinguish fork builds from upstream in the CLI/UI
  • keep release/tag naming CI-friendly and deterministic
• Examples:
  • stable upstream base: 0.111.0-exomind
  • if we later track upstream prereleases, use the same suffixing rule on top of the upstream version string, e.g. 0.112.0-alpha.11-exomind

Implications:

• codex-rs/Cargo.toml workspace version must stop being 0.0.0 and be set from the chosen Exomind release line
• any CLI/version display that currently uses CARGO_PKG_VERSION will then show the fork-specific version automatically
• .github/workflows/rust-release.yml currently rejects -exomind suffixes, so the tag validation regex must be widened before formal Exomind releases can be CI-published

Current state:

• the ad-hoc prerelease exomind-main-a02eeaa7 is only a temporary snapshot artifact for testing
• it should not be treated as the long-term release naming scheme