[Bug]: ocx status/doctor flap service=viable vs service=absent while launchd service is running (2.77.0 macOS)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- macos, typescript
Research direction
Run the provided repeated ocx status and ocx doctor reproduction while checking ocx service status, launchd state, and /healthz; compare the inconsistent results with the class of issue described in #5975. Trace how the CLI commands determine service viability and ownership, then check whether both commands agree when the service is healthy. Done means they consistently report service=viable / protected in that condition.
Written by the indexing model from the issue text.
Description
Summary
On macOS 2.77.0 with a healthy LaunchAgent-managed proxy, ocx status and ocx doctor intermittently report service=absent / "AT RISK for Codex Desktop after restart" while:
launchctl print gui/$(id -u)/com.opencodex.proxyshowsstate = runningocx service statusconsistently reportsinstalled and loaded (launchd)GET /healthzreturns ok for the same PID
Sometimes ocx status and ocx doctor disagree with each other in the same second.
Looks related to the class fixed in #5975 ("CLI startup status can disagree with the live managed proxy"), but still reproduces on 2.77.0.
Environment
- opencodex
@bitkyc08/[email protected] - macOS, LaunchAgent
com.opencodex.proxy RunAtLoad=true,KeepAlive.SuccessfulExit=false- Proxy on
127.0.0.1:10100, default provideropenai(ChatGPT-forward) - Codex CLI 0.160.0 via brew cask + ocx shim
Repro
With the service already installed and serving:
# ground truth — stays healthy across the whole run
launchctl print "gui/$(id -u)/com.opencodex.proxy" | rg 'state =|pid ='
ocx service status
curl -sS http://127.0.0.1:10100/healthz
# flap — run repeatedly
for i in 1 2 3 4 5; do
echo "=== round $i ==="
ocx status 2>&1 | rg 'Restart safety|routing=|Service:'
ocx doctor 2>&1 | sed -n '/Codex restart safety/,+2p'
sleep 2
done
Observed (5 consecutive rounds, same PID 54378, healthz always ok)
| Round | ocx status |
ocx doctor |
ocx service status |
|---|---|---|---|
| 1 | service=viable / protected |
service=absent / AT RISK |
installed and loaded |
| 2 | service=absent / AT RISK |
service=absent / AT RISK |
installed and loaded |
| 3 | service=absent / AT RISK |
service=absent / AT RISK |
installed and loaded |
| 4 | service=viable / protected |
service=viable / protected |
installed and loaded |
| 5 | service=absent / AT RISK |
service=absent / AT RISK |
installed and loaded |
Round 1 is the clearest bug signal: status and doctor disagree while the LaunchAgent and /healthz are fine.
ocx resolve --json also reported ownership.kind=none and takeover.reason=managing-cli-unknown / "service-registration compatibility could not be determined" while the service was live — may be related.
Expected
Once ocx service status / launchd / a live attested /healthz agree the managed service is running, ocx status and ocx doctor should report service=viable / protected, not flap to absent.
Workaround
Treat ocx service status + launchctl + /healthz as ground truth. Ignore intermittent AT RISK lines from ocx status / ocx doctor when those three are healthy.
Related
- #5975 (closed) — same class of false negative when recomputing service state locally
- Dominant language
- TypeScript
- Stars
- 16.9k
- Forks
- 1.3k
- Avg merge
- 8h 20m
- Merged PRs (30d)
- 672
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lidge-jun/opencodex
-
account-pool enhancement needs-design proxy
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
lidge-jun/opencodex#6737 · 1 comment ·
Maintainers usually reply within 1 day
-
account-pool bug needs-design service
Difficulty 4/5 3-5 days Newbie friendliness 48/100
lidge-jun/opencodex#7312 · 1 comment ·
Maintainers usually reply within 1 day
-
Anthropic cache prefixes are rewritten during compaction and image overflow in long Codex turnsPossibly taken A pull request linked to this issue is open or already merged. Openbug provider
Difficulty 5/5 Over a week Newbie friendliness 35/100
lidge-jun/opencodex#7307 · 1 comment ·
Maintainers usually reply within 1 day
-
Add a `perch-cli` provider that runs the official Perch CLI, like `claude-cli`Possibly taken A pull request linked to this issue is open or already merged. Openenhancement provider tools
Difficulty 4/5 3-5 days Newbie friendliness 25/100
lidge-jun/opencodex#7306 · 1 comment ·
Maintainers usually reply within 1 day
-
bug proxy tools
Difficulty 3/5 1-2 days Newbie friendliness 72/100
lidge-jun/opencodex#7298 · 2 comments ·
Maintainers usually reply within 1 day
All issues in lidge-jun/opencodex
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Koenkk/zigbee-herdsman-converters#13540 ·
Maintainers usually reply within 1 day
-
check:passed streams:add
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
iptv-org/iptv#55821 · 1 comment ·
Maintainers usually reply within 1 day
-
area/busola/ux
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
kyma-project/busola#5442 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
vercel-labs/wterm#246 ·
Maintainers usually reply within 1 day