Active goals can auto-continue concurrently across app-server processes

Codex version

Reproduced with codex-cli 0.144.3. The same process-local guards are present on main at 8b2c84ddccafe40dc0dc09f9f52bcbdc9dc45d66.

What happened?

Two app-server processes sharing one CODEX_HOME can independently resume the same thread while its persisted goal is active. Each process sees its own in-memory thread as idle and starts an automatic goal-continuation turn. The turns can overlap and execute tools concurrently in the same workspace.

I observed an existing CLI goal turn remain in flight while two later remote thread/resume requests each launched another real goal-continuation turn.

Reproduction outline

1. Start app-server A with the goals feature enabled.
2. Materialize a persistent thread, set an active goal, and keep its automatic continuation in flight.
3. Start app-server B with the same CODEX_HOME.
4. Send thread/resume for the same thread to app-server B.
5. Observe another automatic continuation and a second turn/started / Responses request while A is still running.

Using a single managed daemon and attaching the TUI with codex --remote unix:// resume avoids the race, but independent app-server processes remain possible (for example a foreground Remote Control host or another Codex surface).

Expected behavior

A second process may resume/read the thread and receive its goal snapshot, but it must not start automatic goal work while another live process owns that thread's goal continuation. If the owner exits or crashes, a later process should be able to continue it.

Source trace

• A cold thread/resume sends the response and then calls emit_resume_goal_snapshot_and_continue:

https://github.com/openai/codex/blob/8b2c84ddccafe40dc0dc09f9f52bcbdc9dc45d66/codex-rs/app-server/src/request_processors/thread_processor.rs#L2822-L2988

• That path emits the thread-idle lifecycle whenever goals are enabled:

https://github.com/openai/codex/blob/8b2c84ddccafe40dc0dc09f9f52bcbdc9dc45d66/codex-rs/app-server/src/request_processors/thread_goal_processor.rs#L66-L77

• GoalRuntimeHandle::continue_if_idle uses a per-runtime semaphore and calls the local thread's try_start_turn_if_idle:

https://github.com/openai/codex/blob/8b2c84ddccafe40dc0dc09f9f52bcbdc9dc45d66/codex-rs/ext/goal/src/runtime.rs#L335-L415

• The thread map, active-turn check, mailbox, and goal semaphore are process-local. The shared thread_goals SQLite row has no owner or lease, so both processes can pass the idle gate.

A goal-specific cross-process advisory lock or ownership lease, released automatically on process death and held for the continuation lifetime, seems like the narrowest fix. This is related to multi-client attachment (#32445, #14722), but it is independently an execution-safety issue.