mirror of
https://github.com/openai/codex.git
synced 2026-05-23 12:34:25 +00:00
f41306b4f3
Follow-up to #19266. ## Why `thread_start_with_non_local_thread_store_does_not_create_local_persistence` is meant to catch accidental local thread persistence when a non-local thread store is configured. The Windows flake reported in [this BuildBuddy invocation](https://app.buildbuddy.io/invocation/0b75dde4-6828-4e7b-a35b-e45b73fb005d) showed that the assertion was tripping on an unexpected top-level `.tmp` entry: ```diff { + ".tmp", "config.toml", "installation_id", "memories", "skills", } ``` That `.tmp` does not appear to come from `tempfile::TempDir`; it comes from unrelated plugin startup work that can legitimately materialize `codex_home/.tmp`, including the startup remote plugin sync marker in [`core/src/plugins/startup_sync.rs`](bce74c70ce/codex-rs/core/src/plugins/startup_sync.rs (L13-L15)) and the curated plugin snapshot under [`.tmp/plugins`](bce74c70ce/codex-rs/core-plugins/src/startup_sync.rs (L25-L26)). That makes the regression race unrelated background startup tasks instead of validating the thread-store invariant it was added to cover. Rather than weakening the assertion to allow arbitrary `.tmp` entries, this change isolates the test from plugin warmups so it can stay strict about unexpected local thread persistence artifacts. ## What changed - disable plugins in the generated config used by `app-server/tests/suite/v2/remote_thread_store.rs` - keep the existing `codex_home` assertions unchanged so the test still fails if local session or sqlite persistence is introduced ## Verification - `cargo test -p codex-app-server suite::v2::remote_thread_store::thread_start_with_non_local_thread_store_does_not_create_local_persistence -- --exact`