Skip to content

feat: restart the Codex app-server daemon on container start#120

Open
BrettKinny wants to merge 1 commit into
mainfrom
feat/codex-app-server-autostart
Open

feat: restart the Codex app-server daemon on container start#120
BrettKinny wants to merge 1 commit into
mainfrom
feat/codex-app-server-autostart

Conversation

@BrettKinny

Copy link
Copy Markdown
Collaborator

Why

The Codex CLI's experimental remote-control feature runs through codex app-server daemon start. The daemon's state (including the enable-remote-control flag) lives in /home/dev/.codex and survives in the squarebox-home volume — 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-entrypoint now restarts the daemon at boot, in both the root (PUID/PGID) and already-unprivileged paths:

  • Opt-in by prior use: only fires when ~/.codex/app-server-daemon/settings.json exists, i.e. the operator has run the daemon before. Boxes that never used it skip the hook entirely — no new env vars.
  • Stale-state cleanup: a fresh container has no codex processes, so the leftover control socket / pid files in the volume are removed first (otherwise the daemon's bind fails with EADDRINUSE, or chases a socket symlink into the wiped /tmp).
  • Runs as dev: in the root path the whole command — including the log redirection — runs under setpriv, so no root-owned files land in the dev home.
  • Never wedges boot: command -v codex no-ops when codex isn't installed; the start is capped at 30s and failure is a non-fatal stderr note.

Testing

  • bash -n clean.
  • Live-verified on the Unraid compose install: after docker restart squarebox, the daemon comes back as dev with --remote-control, socket healthy, ChatGPT pairing working, autostart.log dev-owned.

🤖 Generated with Claude Code

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant