flake: test_codex_monitor.bats teardown intermittently fails with "Directory not empty"

[fujibee]

tests/test_codex_monitor.bats's shared teardown (teardown_test_env in tests/test_helper.bash:38, called from teardown at tests/test_codex_monitor.bats:76) intermittently fails with rm: ... Directory not empty when tearing down $TEST_SKILL_DIR.

Observed instances

When (UTC)	Branch	Run / Job	Platform / shard	Failing test
2026-08-07 09:49	main	run 31166966046 / job 92829964324	macos-latest 3/4	not ok 191 codex-monitor: recreates a stale app-server left by a different codex version
2026-08-07 19:22	main	run 31210935059 / job 92973377008	ubuntu-latest 3/4	not ok 194 codex-monitor: never kills a non-codex process recorded under a reused pid
2026-08-07 21:57	PR #660	run 31221828109 / job 93007897833	ubuntu-latest 1/4	not ok 202 codex-monitor: reuses a live app-server when tasklist cannot see it (#567)

All three show the identical signature:

# (from function `teardown_test_env' in file tests/test_helper.bash, line 38,
#  from function `teardown' in test file tests/test_codex_monitor.bats, line 76)
#   `teardown_test_env' failed
# rm: ...: Directory not empty

Why this points at the file's own teardown, not shard/test interference

The three instances span two different platforms (macOS, Linux), two different shard positions (3/4, 1/4), and three different specific @test names within the file. The only constant across all three is tests/test_codex_monitor.bats and its shared teardown failing the same way. That rules out shard composition or a specific adjacent test as the cause of any one instance -- whatever is causing the "Directory not empty" race is intrinsic to this file's teardown itself.

(Unconfirmed hypothesis, not verified: each of this file's tests spawns a real codex-monitor.sh app-server background process, which could still hold a file open under $TEST_SKILL_DIR when teardown_test_env's rm -rf runs. Not investigated further here.)

Root cause not investigated -- this file's tests are tied to the still-open #567 work. Filing this as its own tracking issue since the flake itself is orthogonal to that.

[fujibee]

4th instance

Reported by a teammate from PR #661 (a docs-only change — README.md/README.ja.md/llms.txt — with no code path to this test at all), independently re-verified via the job logs directly:

When (UTC)	Branch	Run / Job	Platform / shard	Failing test
2026-08-07 22:06	PR #661	run 31221896120 / job 93008109166	macos-latest 1/4	not ok 197 codex-monitor: recreates a stale app-server left by a different codex version

Same signature:

# (from function `teardown_test_env' in file tests/test_helper.bash, line 38,
#  from function `teardown' in test file tests/test_codex_monitor.bats, line 76)
#   `teardown_test_env' failed
# rm: /var/folders/df/djsxfhc17x95674wsm_g8s980000gn/T/tmp.zlKI0YjuzK: Directory not empty

A rerun on the next head (32f3721) passed on the same shard. This is now 4 independent instances (2 main, 2 PR branches — one docs-only) across both platforms, four different shard positions (3/4, 1/4, 3/4, 1/4), and three distinct specific test names within the file (recreates a stale app-server... recurring twice). Further reinforces that this is intrinsic to test_codex_monitor.bats's own teardown, not tied to any particular diff, shard composition, or adjacent test.

[fujibee]

Observed another instance on PR #733, head b393507d51c42b0742a9c0b2539ce75a15ebca29 (Actions run 31371497242, job 93401307899).

The first Windows-runtime test reached teardown and then failed only there:

not ok 1 codex-monitor: windows-native reaches the bridged handoff (#567)
(from function `teardown_test_env` in file tests/test_helper.bash, line 38)
`teardown_test_env` failed
rm: cannot remove '/tmp/tmp.4bhaik75cO': Directory not empty

There was no no bridge was started line in this failure. The other bridge-specific test in the same job completed successfully:

ok 2 launcher: windows-native starts the bridge (#567)

A rerun of the failed job passed on the same head. The failing leg executes only tests/test_codex_monitor.bats and tests/test_codex_bridge_launcher.bats; the PR changed endpoint validation paths that neither test invokes. This observation therefore matches this issue's teardown-only failure, rather than the combined teardown-plus-bridge-start failure tracked separately.

[fujibee]

This symptom and the one in #709 ("no bridge was started", no teardown failure) came out of the same commit, on different runs of the same job.

fujibee/agmsg#746, head 1d82ef28cfc986936b10df698cfb107303e85c0d, three runs of bats (windows-latest, windows runtime (#567)), no push between them:

run	codex-monitor: … bridged handoff	launcher: … starts the bridge
1	ok	not ok — no bridge was started
2	not ok — teardown, rm: cannot remove '/tmp/tmp.8364dVj1EO': Directory not empty	ok
3	ok	ok

Run 2 is this issue. Run 1 is #709. Nothing changed between them.

"Intermittently" in the title is right, and the measurement above puts a floor under it: this is not a rare tail — one job, one commit, three answers. #699 records the same-SHA inversion; this issue and #709 are two of the faces it turned up.

What it does not establish: that the two symptoms share a mechanism. Only that a difference in symptom between runs is not evidence that they do not. Neither mechanism is identified here — this leg reproduces on Windows and I could not run it (macOS).