feat: restart the Codex app-server daemon on container start#120
Open
BrettKinny wants to merge 1 commit into
Open
feat: restart the Codex app-server daemon on container start#120BrettKinny wants to merge 1 commit into
BrettKinny wants to merge 1 commit into
Conversation
The daemon behind `codex app-server daemon start` / remote control keeps its state in the home volume, but the process dies with the container — so Codex remote control silently drops on every restart (e.g. a nightly appdata backup cycle) and has to be brought back by hand. The entrypoint now restarts it at boot when its settings file shows the operator used it before, after clearing the stale control socket and pid files a dead container leaves in the volume. Best-effort and capped at 30s so a broken install or dead network can never wedge boot; boxes that never ran the daemon skip it entirely. Verified on a live Unraid compose install: daemon comes back as dev with remote control connected after docker restart. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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.
Why
The Codex CLI's experimental remote-control feature runs through
codex app-server daemon start. The daemon's state (including theenable-remote-controlflag) lives in/home/dev/.codexand survives in thesquarebox-homevolume — but the process itself dies with the container. Every container restart (e.g. a nightly appdata backup cycle on Unraid) silently drops remote control until someone execs in and starts it again by hand.What
squarebox-entrypointnow restarts the daemon at boot, in both the root (PUID/PGID) and already-unprivileged paths:~/.codex/app-server-daemon/settings.jsonexists, i.e. the operator has run the daemon before. Boxes that never used it skip the hook entirely — no new env vars.EADDRINUSE, or chases a socket symlink into the wiped/tmp).setpriv, so no root-owned files land in the dev home.command -v codexno-ops when codex isn't installed; the start is capped at 30s and failure is a non-fatal stderr note.Testing
bash -nclean.docker restart squarebox, the daemon comes back asdevwith--remote-control, socket healthy, ChatGPT pairing working,autostart.logdev-owned.🤖 Generated with Claude Code