[skulitom]

The quick self-test spends most of its time in fixed waits. This makes four checks wait for the condition they need instead, which saves 5.0 s (15%) per selftest --quick run: 32.8 s → 27.9 s. Every assertion is kept except one that can't fail, and product coverage is unchanged line for line. Product code is untouched.

What changed

Check	Was	Now	Saved	What still pins the behaviour
MCP ownership	After the simulated quit, the two calls each waited out McpServer's default 1 s connect to the closed pipe.	The stale backend gets ConnectTimeoutMs = 50, as McpChecks.Discovery and ChannelChecks already use. It is set only after Windows lists the stand-in's pipe (SeatSlot.Pipes(), bounded at 5 s), because JsonPipeServer.Start() opens its first instance on a background task and a 50 ms connect could otherwise race it on a slow runner.	1.87 s	The same assertions: LeaseEnded, the token dropped, the acquire hint, no launch and no readiness call.
MCP lease helper	await Task.Delay(1500) for the waiter to join the line.	Polls the lease's status (every 10 ms, bounded at 5 s) until one agent is waiting. Its first ask joins the line, so this takes a few ms. The grant after release still waits for the helper's own 1 s re-ask, which is product behaviour.	1.01 s	Unchanged: the owner hears "Another agent is waiting", and the waiter gets the desktop on release.
agent deadline replies	The read-only (desktop.wait) and command-start (exec.start) cases ran with 1,000 ms deadlines and waited out 875 ms each.	300 ms (263 ms waits). Neither case asserts its time text. Both stay in StopAfterMs's eighth branch and the N ms message branch. The queued 800 ms and held 1.5 s cases are unchanged, so the asserted "800 ms" and "1.5 s" messages and log lines (the nearest cases to the 1,000 ms format switch) still pin the format.	1.24 s	The same timed_out, started and message assertions.
pipe forwarded time left	Queued the request behind a slow one for 1.5 s, then asserted left <= 8000 - 1400 && left > 8000 - 4500.	0.6 s, with left <= 8000 - 500 && left > 8000 - 3600. That keeps the same 100 ms early margin and 3 s late margin, and stays well above TimeLeft's 100 ms floor. The "starved" case (1,000 ms deadline, 960 ms wait) is unchanged: its 60 ms margin against a TickCount64 clock leaves no room to shrink it.	0.90 s	The same assertion shape.
desktop ignored set_value	Require(window.Value == "Free" && watch.ElapsedMilliseconds >= ...)	Drops window.Value == "Free". In "ignore" mode the stand-in's SetValue never writes _value, and Use() has just reset it to "Free", so that conjunct only restates the fixture and no product change can make it fail.	0	The elapsed-time half of the line, the "still showed its old value" throw with no quoted text and with the list advice, and the "late" case.

Before and after

Measured on main 98173de against this branch, with Release builds run alternately (main, branch, ×3) on the same PC:

	main 98173de	this branch
Quick checks	99 pass, 0 fail	99 pass, 0 fail
anode selftest --quick wall time	32.91, 32.79, 32.77 s	27.82, 27.87, 27.90 s
Sum of check times	32.7, 32.6, 32.6 s	27.6, 27.7, 27.7 s
build.ps1 -QuickTest (publish, self-test, docs check)	passes	passes (twice)
Product line coverage (Debug, dotnet-coverage 18.11.2)	6,281 of 10,736 lines (58.50%)	the same 6,281 lines exactly

Mutation check

Product mutations aimed at the changed checks (mutate.py: apply, build Debug, run selftest --quick, restore byte for byte). With this branch's checks, every one is caught by the check named:

Mutation	Caught by	How
O1: a lease-gated call after quit may start a daemon	MCP ownership	"a cached lease token launched a daemon"
O2: a lease-gated call after quit keeps its token	MCP ownership	"kept its token or hid the acquire hint"
L1: the owner isn't told when one agent is waiting	MCP lease helper	"the owner was not told another agent is waiting"
L2: the MCP helper stops asking after its first busy answer	MCP lease helper	"the waiting agent did not get the released desktop"
D1: read-only and acting replies swapped	agent deadline replies	the held 1.5 s case
D2: an action stopped partway reported as never started	agent deadline replies	the held 1.5 s case
D3: a cut-short command start loses the job-list advice	agent deadline replies	the 300 ms exec.start case
D4: a cut-short desktop.wait said to have acted	agent deadline replies	the 300 ms desktop.wait case
F1: the daemon forwards the full time, not the time left	pipe forwarded time left	forwarded 8000 ms of 8000
F2: only half the queued time is counted	pipe forwarded time left	forwarded 7696 ms of 8000

The same nine mutations (O1 to F2) against main's checks, as a control: all nine caught too. D1 and D2 are caught by the unchanged held 1.5 s case before the shortened cases run, so D4 was added to show that the 300 ms read-only case catches on its own.

On this PR's CI run (38024123972) the changed checks took 136 ms (MCP ownership), 1,006 ms (MCP lease helper), 2,558 ms (agent deadline replies) and 1,569 ms (pipe forwarded time left), the same as on this PC.

Second review

codex exec review --base main (gpt-6-astra, sandbox: read-only, through the Compass wrapper): "No actionable regressions were found in the test-only changes. The revised timing and polling remain consistent with the code being tested." The routine's question (does any changed or removed assertion lose the only coverage of a behaviour, or add timing sensitivity) was put to it in the commit message. A separate read-only audit of the checks added in #20 to #32 found the window.Value conjunct above as the only useless assertion. Everything else in those checks pins its own path.

Auto-merge by compass-merge at its next run if tests pass. Add the hold label or leave a comment to stop it. (This repository has no hold label, so a comment holds it.)

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-10-10T04:29:34.148420Z	49be05f	PR opened

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.