Survive a missing nohup, and diagnose a proxy that won't start - #13
Merged
Conversation
…t start Found while testing the release-tarball path on a machine with no Homebrew — the path a non-technical user actually takes, and the one nothing had exercised until now (both real installs so far found an existing binary). The tarball path itself works: 59 MB binary downloaded, feature-gate satisfied, config written, GPT and Claude both answering through it, proxy cleaned up on exit. Two things it exposed: - start_proxy hard-depended on `nohup`. Present everywhere in practice, but a background job with the same redirect works without it, so fall back rather than failing. - "proxy failed to start — see proxy.log" pointed at an EMPTY log, which is precisely the case where the log cannot help: the binary never ran. The message now distinguishes the two and prints the command to run by hand.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
From testing the release-tarball path with no Homebrew — the path a professor actually takes, and the only install path nothing had exercised (both real installs so far found an existing
cliproxyapi).The path works
Verified in a sandbox with no
brewand nocliproxyapion PATH: 59 MB binary downloaded from the GitHub release, feature-gate satisfied (v7.2.137 hasdisable-cloaking-model-list), config written, GPT and Claude both answering through it, proxy cleaned up on exit.Two gaps it exposed
start_proxyhard-depended onnohup. It's present everywhere in practice — my sandbox just didn't symlink it — but a plain background job with the same redirect does the same work, so it now falls back instead of failing outright.The failure message pointed at an empty log. "proxy failed to start — see proxy.log" is useless in exactly the case that produces it: the binary never ran (missing dep, wrong arch, quarantine), so the log is empty. It now distinguishes an empty log from a populated one, prints the last lines when there are any, and otherwise gives the exact command to run by hand — plus a reminder that Claude models are unaffected.
Verified both branches: with
nohupremoved from PATH, a GPT session still works end to end and still cleans up.Suites green (routing 6/6, shellcheck, bash 3.2).