[teamleaderleo]

debug.creation.hold / debug.creation.release and debug.close.hold / debug.close.release are registered again on a Debug build's control socket.

#29409 (P0 close-then-type) registered the local daemon's creation-hold and close-read-hold methods beside debug.daemon in AppControl:

service.router.register(DebugWindowsControl.methods(services) + [services.daemon.debugControlMethod { … }] + services.daemon.creationHold.methods + services.daemon.closeReadHold.methods)

#28295 (debug.daemon_requests, b9abd53) landed after it with its own copy of that line, which added debugRequestLatencyMethod() and dropped both hold lists. Nothing else on feat-cmux-next registers them (git grep "creationHold.methods" finds no caller), so a Debug app answers those four methods with an unknown-method error. scripts/cmux-next/typeahead-gate.sh and the journey fuzz (scripts/journeys/ext_fuzz.py) drive them. #28295's own description doesn't mention removing them, so this looks like a merge loss. This PR puts them back beside debug.daemon_requests. It's a one-line change.

Found while investigating the cmux-next crash ends the app base red. That red is not caused by this, and this PR does not fix it. See the follow-up evidence on the crash-gate diagnostic PR.

Checks: app compile check passed at e467a95; scripts/cmux-next/prepush-gate.py reports no new violations.

Agent session: agent session

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

---

Summary by cubic

Restores debug.creation.hold/release and debug.close.hold/release on a Debug build's control socket. #28295 replaced the registration line in AppControl and dropped both hold lists, so Debug builds answered those four methods with an unknown-method error. This puts them back beside debug.daemon_requests. It's a one-line change; this does not fix the cmux-next crash ends the app red it was found investigating.

^{Written for commit e467a95. Summary will update on new commits.}

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review e467a95: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr32238 -f ref=lane/crash-gate-socket -f platform=macos -f backend_mode=local

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4144668469201 (91cf7c0aa8)
• cmux NEXT nightly 1.0.0-nightly.4144754641401 (f2a2b6d444)
• cmux NEXT nightly 1.0.0-nightly.4144882653901 (612c99d3c9)
• cmux NEXT nightly 1.0.0-nightly.4144971038501 (5f937c4fc4)
• cmux NEXT nightly 1.0.0-nightly.4145066734501 (6fdfe98ecd)
• cmux NEXT nightly 1.0.0-nightly.4145248477801 (7bfeec05fd)
• cmux NEXT nightly 1.0.0-nightly.4145363708701 (c81ea581fe)

[teamleaderleo]

Review (claude-opus-5-5): SHIP at e467a95

Review (subagent claude-opus-5-5): SHIP at e467a95
Restores #29409's + services.daemon.creationHold.methods + services.daemon.closeReadHold.methods tail exactly as b9abd53 dropped it, now after the newer debugRequestLatencyMethod() element; both are [ControlMethod] on @mainactor classes (unchanged since the drop) and debug.creation.*/debug.close.* are registered nowhere else, so nothing is registered twice.
Follow-ups: [follow-up] the one-line register expression is long; splitting the holds into their own service.router.register(...) call would make a future merge less likely to drop them again.