## Why
Releases can contain different resources while shipping identical executable bytes. The daemon must recognize those release changes, while a stale updater should be able to hand off without restarting an already-current daemon.
## What changed
- Include a digest of the resolved executable path in `ExecutableIdentity` to distinguish release generations with identical binaries.
- Keep content-only comparisons for package preparation and manual update reporting.
- Check the running daemon's identity and version before restarting during updater adoption, manual updates, and production restoration. Preserve scheduled retries when the daemon is not ready.
## Testing
Add coverage for path-sensitive identity, scheduled no-op updates that preserve the daemon, and resource-only release updates that restart it despite identical executable bytes.
GitOrigin-RevId: bbea06cf502abb2251e70d4ba4b422cae867116c
## Why
Debug executables can be hundreds of megabytes. Computing their identity previously loaded the entire file into memory and hashed it on an async runtime thread.
## What changed
Stream executable contents into the BLAKE3 hasher using `tokio::task::spawn_blocking`, preserving the existing digest format while avoiding whole-file allocation and moving hashing off the async runtime.
## Testing
Expand the executable identity test to verify compatibility with whole-file hashing for a file spanning multiple reads with a partial final buffer and for an empty file, and to confirm that changing a byte changes the identity.
GitOrigin-RevId: 528103397395313d170ec720fefc8c5ab3676956
## Why
`bootstrap` starts a detached pid-backed updater loop, but before this
change that updater could keep running an old executable image even
after `install.sh` replaced the managed standalone binary under
`CODEX_HOME`. That left the updater itself behind the binary it had just
rolled out, especially when the app-server was stopped or when the
managed binary changed without a version-string change.
## What changed
- Track updater identity from the executable contents rather than only
the reported CLI version.
- Force the managed app-server restart path when the managed binary
contents differ from the running updater image, then re-exec the updater
from the managed binary once the rollout is in a safe state.
- Distinguish a genuinely absent managed app-server from a managed
process that exists but is not yet probeable, so self-refresh does not
skip a required restart.
- Keep the restart/re-exec decision under the daemon operation lock so
`bootstrap` cannot race the handoff.
- Update `app-server-daemon/README.md` to document the resulting
standalone and out-of-band update behavior.
## Verification
- `cargo test -p codex-app-server-daemon`
- `just fix -p codex-app-server-daemon`
Added focused unit coverage for:
- content-based updater refresh decisions
- safe updater re-exec outcomes across restart states
## Why
Desktop and mobile Codex clients need a machine-readable way to
bootstrap and manage `codex app-server` on remote machines reached over
SSH. The same flow is also useful for bringing up app-server with
`remote_control` enabled on a fresh developer machine and keeping that
managed install current without requiring a human session.
## What changed
- add the new experimental `codex-app-server-daemon` crate and wire it
into `codex app-server daemon` lifecycle commands: `start`, `restart`,
`stop`, `version`, and `bootstrap`
- add explicit `enable-remote-control` and `disable-remote-control`
commands that persist the launch setting and restart a running managed
daemon so the change takes effect immediately
- emit JSON success responses for daemon commands so remote callers can
consume them directly
- support a Unix-only pidfile-backed detached backend for lifecycle
management
- assume the standalone `install.sh` layout for daemon-managed binaries
and always launch `CODEX_HOME/packages/standalone/current/codex`
- add bootstrap support for the standalone managed install plus a
detached hourly updater loop
- harden lifecycle management around concurrent operations, pidfile
ownership, stale state cleanup, updater ownership, managed-binary
preflight, Unix-only rejection, forced shutdown after the graceful
window, and updater process-group tracking/cleanup
- document the experimental Unix-only support boundary plus the
standalone bootstrap/update flow in
`codex-rs/app-server-daemon/README.md`
## Verification
- `cargo test -p codex-app-server-daemon -p codex-cli`
- live pid validation on `cb4`: `bootstrap --remote-control`, `restart`,
`version`, `stop`
## Follow-up
- Add updater self-refresh so the long-lived `pid-update-loop` can
replace its own executable image after installing a newer managed Codex
binary.
Eric Traut