fix(cli): match macOS framework Python in stop/restart gateway detection - #2523
Conversation
The _args_look_like_kirocrew module-invocation guard required a preceding token whose basename starts with "python", but the check was case-sensitive. The macOS framework build's interpreter basename is "Python" (capital P), so "Python -m kiro_crew gateway" failed the guard: kirocrew stop and restart reported "No Kiro Crew gateway currently running" and no-oped on macOS framework-build installs (Toolbox being the common one), even with the gateway live on the port. Lower-case the interpreter basename before the prefix match, and add the framework-Python launch forms to the classifier tests.
Opus 4.8 Review (fork) — ✅ no blocking findingsReviewed Review detailsNo findings. The change makes the Python-interpreter basename check case-insensitive ( [OPUS-REVIEWED] d91c8cd |
Design Review (Fable 5, fork) — ✅ PASSAdvisory design-level review of Design-Verdict: PASS A real macOS-only failure, fixed at the exact structural check that caused it, with regression tests pinning both spawn forms. [DESIGN-REVIEWED] d91c8cd |
GPT 5.6 Review (fork) — ✅ no blocking findingsReviewed Review detailsNo findings. |
…ion (kirodotdev#2523) The _args_look_like_kirocrew module-invocation guard required a preceding token whose basename starts with "python", but the check was case-sensitive. The macOS framework build's interpreter basename is "Python" (capital P), so "Python -m kiro_crew gateway" failed the guard: kirocrew stop and restart reported "No Kiro Crew gateway currently running" and no-oped on macOS framework-build installs (Toolbox being the common one), even with the gateway live on the port. Lower-case the interpreter basename before the prefix match, and add the framework-Python launch forms to the classifier tests. Co-authored-by: Marc El Naameh <mnaameh@amazon.com>
Problem / Motivation
On macOS,
kirocrew stop(andrestart) print "No Kiro Crew gateway currently running on port" even when the gateway is live and listening on that port — so neither command can stop the server.
Why it matters
Hits any macOS install whose interpreter is a framework build (Toolbox is the common one):
stopis a no-op andrestartcan't kill the old gateway then fails to rebind, whilestatusstill reports "running" — the commands contradict each other. Users fall back tokill $(lsof -ti TCP:<port> -sTCP:LISTEN).What changed (motivation → approach → change)
kirocrew stopsays no gateway while one is listening on the port._stop/_restartlocate the PID vialsof, then gate the kill on_is_kirocrew_process→_args_look_like_kirocrew. The module-invocation branch requires a token before-mwhose basename starts with "python", but the check was case-sensitive (_basename_stem(t).startswith("python")). A macOS framework build's interpreter basename isPython(capital P) — e.g..../Python.app/Contents/MacOS/Python -m kiro_crew gateway— so the guard rejects the real gateway and the command no-ops._basename_stem(t).lower().startswith("python")). One line; strictly widens to includePython/PYTHON, no effect on the negative cases (which fail for structural reasons, not interpreter case).Tests
Added two launch forms to
TestArgsLookLikeKirocrew.test_matches_server_launch_forms: a macOS framework path (/Library/Frameworks/Python.framework/Versions/3.10/Resources/Python.app/Contents/MacOS/Python -m kiro_crew gateway --no-open) and a barePython -m kiro_crew gateway. Both fail before the fix and pass after; existing negative cases (GATEWAY,grep -m,run gateway, editor) unchanged.Manual verification
Reproduced on macOS: gateway live on the port (
lsofshowsPython … (LISTEN)),kirocrew stopprinted "No Kiro Crew gateway currently running";ps -o command=confirmed the process is.../Python.app/Contents/MacOS/Python -m kiro_crew gateway. With the fix, the classifier recognizes that command line.Related Issues
None found in a search of open issues/PRs.
Checklist
fix(cli): ...)