diff --git a/.codex/flaky-test-triage.md b/.codex/flaky-test-triage.md
index c3e70182c4..94504c4923 100644
--- a/.codex/flaky-test-triage.md
+++ b/.codex/flaky-test-triage.md
@@ -81,6 +81,7 @@ Older failures also appeared on Linux, but the repeated cross-PR signal is stron
   - Run `23177624353` on doc-only head `65f7f64ae` failed only in `Tests — ubuntu-24.04 - x86_64-unknown-linux-gnu`, in `codex-core::all::suite::code_mode::code_mode_yield_timeout_works_for_busy_loop`. The only diff from the prior green head `4a3181290` was one extra line in this tracking document, so the failure exposed a latent flake rather than a branch regression.
   - CI annotation `67343276143` showed the busy-loop test yielded only the synthetic `Script running with cell ID ...` header and missed the expected `phase 1` output item. The root cause is in `core/src/tools/code_mode/runner.cjs`: the initial `yield_time_ms` timer started when the worker was created, so on a loaded runner the `100ms` budget could expire before the worker had begun executing `text("phase 1")`.
   - Current follow-up: make the worker emit an internal `started` message and arm the initial yield timer only after that signal arrives, so `yield_time_ms` measures script execution time instead of worker startup delay.
+  - Runs `23178075559` (`rust-ci`) and `23178075565` (`Bazel (experimental)`) finished green on head `d8450f8e2`. The code-mode runner now starts the initial yield timer only after the worker signals that execution has started, so `code_mode_yield_timeout_works_for_busy_loop` no longer races against worker startup latency. This is pass 1 of 5 after the latest failing run.
 - Rationale: these failures are test-harness flakes, not product behaviors. The fixes keep the assertions intact and remove environment-sensitive startup and ordering hazards instead of stretching timeouts.
 
 ## Constraints
@@ -125,3 +126,4 @@ Older failures also appeared on Linux, but the repeated cross-PR signal is stron
 | `6a302cb2e` | Encode Windows apply_patch read command | failed | Run `23176240418` kept all non-Windows jobs and `Bazel (experimental)` green, but both Windows `Tests` shards still failed in `all::suite::apply_patch_cli::apply_patch_cli_can_use_shell_command_output_as_patch_input`. Check-run annotations `67338924441` and `67338924464` showed the nested `powershell.exe` read was now executing, but it appended `CLIXML` progress output (`Preparing modules for first use.`) after the expected file contents. The next follow-up suppresses PowerShell progress records, uses `[System.IO.File]::ReadAllText(...)`, and adds `-NonInteractive` so the shell tool output stays deterministic. |
 | `4a3181290` | Suppress PowerShell CLIXML in apply_patch test | full pass | Runs `23176985939` (`rust-ci`) and `23176985980` (`Bazel (experimental)`) finished green for the full PR, including both Windows `Tests` jobs. The Windows `cmd.exe` harness now keeps the nested UTF-8 PowerShell read but suppresses progress records, switches to `[System.IO.File]::ReadAllText(...)`, and adds `-NonInteractive` so the shell tool returns only the source bytes. This is pass 1 of 5 after the latest failing run. |
 | `65f7f64ae` | Record validation pass 1 | failed | Run `23177624353` failed only in `Tests — ubuntu-24.04 - x86_64-unknown-linux-gnu`, in `codex-core::all::suite::code_mode::code_mode_yield_timeout_works_for_busy_loop`, while `Bazel (experimental)` run `23177624352` finished green on the same head. The only diff from the prior full-green head `4a3181290` was one extra line in this tracking document, so the failure exposed a latent code-mode yield race: the runner started the initial `yield_time_ms` timer when the worker was created, allowing the `100ms` budget to expire before the worker began executing user code on a loaded CI machine. |
+| `d8450f8e2` | Fix code mode yield startup race | full pass | Runs `23178075559` (`rust-ci`) and `23178075565` (`Bazel (experimental)`) both finished green for the full PR, including the previously flaky `Tests — ubuntu-24.04 - x86_64-unknown-linux-gnu` shard and both Windows `Tests` jobs. The code-mode runner now starts the initial yield timer only after the worker signals that execution has started, so `yield_time_ms` measures script runtime rather than worker startup latency. This is pass 1 of 5 after the latest failing run. |