## Why
`codex app-server daemon update` previously required a latest-channel installation, leaving pinned and local managed packages unable to return to production updates through that command.
## What changed
- Allow explicit updates to restore managed packages to the latest stable release while preserving the automatic-update preference. Extend legacy migration to local and pinned packages when the published installer and release support it.
- Bind restoration to the selected release with a single-use updater authorization and installer guards. Scheduled updates and ordinary updater socket requests continue to respect pins.
- Restart a running daemon when its selected package changes, even if the binary and version are identical; leave stopped daemons stopped.
- Reject incompatible production packages before selecting them, resolve Windows junction targets for ownership checks, and show the restoration command after installing a pinned CLI package.
## Testing
Extend daemon and installer tests to cover local-package migration, restoration with automatic updates enabled or disabled, same-binary package restarts, stopped-daemon preservation, selection races, incompatible releases, and socket requests that must not undo pins.
GitOrigin-RevId: d64520c1190b5c7bac084fb4a1b6b24998b08dfa
## Why
Locale, timezone, or system clock changes can alter the `ps` start-time text used to identify a running daemon, causing its PID record to be treated as stale.
## What changed
- Record and check native process identities on Linux and macOS, using boot IDs to reject records from previous boots and native process details to detect PID reuse.
- Keep `processStartTime` for older clients and promote verifiable legacy daemon and updater records when the updater starts.
- Retain legacy records and report an error when a live process's start-time text no longer matches. Propagate Windows process-access errors instead of treating inaccessible PIDs as stale.
## Testing
Add regression coverage for locale and timezone changes, altered legacy timestamps, legacy record promotion, PID reuse, previous boots, and macOS process ownership differences. Extend zombie-reaping coverage to native identities and verify that Windows access-denied errors are preserved.
GitOrigin-RevId: b5752497c0e8186bb604fe5dd33f570acc068f20
## What changed
Add `codex app-server daemon update --from-cli` to copy and pin the invoking CLI's complete package, including downgrades and local builds. Require interactive confirmation or `--yes`, and warn that restarting a running daemon may interrupt work.
Validate and stage the package before stopping the daemon, recheck the selection and running state after confirmation, and restart only a previously running daemon. Migrate legacy daemon installations to the dedicated package directory while preserving the standalone CLI selection. Explicit replacements disable automatic package updates.
## Testing
Add coverage for cancellation, packages changed during confirmation, version pinning, and legacy migration. Extend CLI integration tests to verify noninteractive confirmation requirements, rejection of incomplete packages without stopping the daemon, and successful replacement and restart.
GitOrigin-RevId: 2d971d6f0259aa576a15a8b115ca9d0e89060fdf
## Why
Daemon lifecycle commands previously required a standalone managed installation. A complete CLI package can supply the daemon executable and helpers without requiring a separate installer run.
## What changed
- Let `codex app-server daemon start`, `restart`, and `bootstrap` copy the invoking package into `CODEX_HOME/packages/app-server-daemon` when no daemon installation exists.
- Validate the package's platform, required helpers, executable identity, and copied contents before selecting the staged release.
- Preserve existing dedicated and legacy daemon selections, reject broken selections instead of replacing them, and leave the CLI package and selection unchanged.
- Preserve standalone release pins and latest-channel eligibility, and select dedicated releases using Unix symlinks or Windows junctions.
## Testing
Add package preparation tests for complete copies, incomplete packages, broken selections, legacy preservation, and update-channel handling. Add Windows junction creation and retargeting coverage, plus CLI integration tests that launch the copied package through `start`, `restart`, and `bootstrap`.
GitOrigin-RevId: abd2f4f82eae0885434ea30603c2c1c0ca760bef
## Why
The daemon shares the standalone CLI package, coupling daemon updates to the visible CLI installation. A dedicated package lets daemon updates preserve the CLI selection and shell profile.
## What changed
- Add dedicated daemon package selection and separate daemon and updater PID files, with diagnostics for the new files.
- Make `codex app-server daemon update` migrate eligible legacy stable latest-channel installations to a dedicated package. Prepare and validate the release and its package-ownership support before switching; preserve settings and whether the daemon was running. Scheduled updates keep legacy installations in place.
- Add daemon-only and deferred-selection modes to the shell and PowerShell installers, leaving the visible CLI installation unchanged.
- Coordinate migration with installer locks, refresh package selection after acquiring lifecycle locks, and reject package changes during update downloads.
## Testing
Add coverage for running and stopped migrations, incompatible installers and releases, package-selection races, daemon-only updates, and a capability probe that does not start an updater. Add a shell installer regression test verifying that daemon installation preserves the visible CLI and shell profile.
GitOrigin-RevId: 1ec0f358f8f6ebde7daddb74e880cc8d2235d647
## What changed
- Atomically save successfully persisted, loaded root thread IDs to `app-server-daemon/loaded-threads.json` during graceful managed shutdown, excluding ephemeral threads and threads pending unload.
- Clear stale recovery state at startup and around daemon lifecycle operations, including explicit stops and fresh starts.
- Probe support for `--managed-daemon` before launching managed app servers, and clear recovery state best-effort when launching older binaries.
- Keep forced shutdown responsive while saving the snapshot and log snapshot failures without preventing shutdown.
## Testing
Add coverage for snapshots after active turns finish, forced shutdown without a snapshot, excluded threads, snapshot write failures, and recovery-state cleanup for stops, fresh starts, and legacy launches.
GitOrigin-RevId: 422dc32b85355510f7e4c57b7540597b47d9f0b2
## Why
Managed app-server shutdowns use a fixed 60-second grace period. Allow users to adjust how long shutdown waits before forcing the process to exit.
## What changed
- Add `shutdownGraceSeconds` to daemon settings, accepting integers from 0 through 300 and defaulting to 60. Zero requests graceful shutdown and then forces termination immediately.
- Apply the setting to managed app-server stops and restarts, including updater-triggered restarts, and extend the lifecycle lock timeout to accommodate the maximum grace period.
- Keep `stop` usable with unreadable or invalid settings by falling back to the default grace period.
## Testing
Add tests for setting defaults and bounds, invalid-value fallback, preservation when saving remote-control settings, graceful process exit, and forced termination with zero or finite grace periods.
GitOrigin-RevId: 8627b391323cf27b40df96935a82e66aa715f572
## What changed
Add `codex app-server daemon update` to check the latest stable release once, even when automatic updates are disabled. The command requires an installer-owned latest-channel standalone installation and reports `updated`, `noUpdate`, or `unsupported` as JSON, including installed and running versions.
Route manual requests through the updater so scheduled and manual installs share one owner and accepted updates continue if the CLI exits. Restart a running managed daemon when its binary or version differs from the selected installation; this may interrupt active or queued work. Return installer failures as command errors and retry requests across updater replacement.
## Testing
Add coverage for manual updates with automatic updates disabled, queued requests, same-version binary replacement, updater handoff retries, and unsupported installations or unmanaged servers.
GitOrigin-RevId: 240b63c79bae3a64a80768131a30da70900a4d62
## Why
An installer can retarget the selected executable symlink or junction while an app server is running. Recording the launch-time identity preserves which binary was started after that path changes.
## What changed
- Resolve the executable path before launching on all platforms and store an optional executable identity in app-server PID records. Continue accepting older records without this field and expose the identity only for an active process.
- Use BLAKE3 for executable identity digests and make `ExecutableIdentity` serializable.
- Schedule updater checks with an explicit deadline in `tokio::select!`, preserving persisted update intervals, settings-error retries, and termination handling.
## Testing
Add a Unix test that verifies the recorded identity matches the resolved launch binary, differs from a retargeted symlink's binary, and remains optional when reading legacy PID records.
GitOrigin-RevId: 4821130b9a5e75b417a8e39c583b30427a872ff8
## Why
The managed daemon's updater used a fixed hourly cadence with no saved preference to disable automatic updates.
## What changed
- Read `updater.autoUpdateEnabled` and `updater.updateIntervalMinutes` from `CODEX_HOME/app-server-daemon/settings.json`, defaulting to enabled with a 60-minute interval. Keep the initial five-minute delay and require a positive interval.
- Apply the enabled preference during daemon lifecycle operations and re-read settings before updates and recurring waits. Preserve updater preferences and unknown fields when saving remote-control settings, using atomic file replacement.
- Signal the updater's process group on Unix so stopping it also terminates installer children. Allow daemon shutdown even when settings are malformed.
- Document updater configuration and remote-control preference behavior. Manual `codex update` remains unaffected.
## Testing
Add tests for settings preservation, interval validation, recurring waits, enabling and disabling updates across restart and bootstrap, Unix installer termination, and shutdown with malformed settings.
GitOrigin-RevId: 5dbb72c5939e9ced2390b3760a7265608c8b61a0
## Why
Starting a latest-channel standalone daemon required a separate `bootstrap` to enable automatic updates. A missing updater could also leave a running server without automatic updates until `bootstrap` was run again.
## What changed
- Ensure a single supported updater after managed `start`, `restart`, and restarts caused by remote-control changes. Repeated starts recover a missing updater while reusing the running server.
- Report updater failures as warnings so successful server starts and restarts still succeed.
- Preserve an existing updater while the latest-channel marker and managed binary may be temporarily inconsistent during installation. Stop it when the latest-channel marker is removed.
- Document automatic updater startup and the limitations of detecting out-of-band binary replacements.
## Testing
Add Unix tests for updater reuse and recovery, invalid updater records, marker mismatches and release pinning, unmanaged servers, and bootstrap status for managed local builds.
GitOrigin-RevId: 44148a8d65709f68def2072f542494620d7e574b
## Why
Bootstrapping the app-server daemon should preserve an explicitly selected release, even when that version is currently `latest`. Older managed binaries should also be able to serve app-server without supporting the updater command.
## What changed
- Record `latest` selections in `auto-update-version` in both standalone installers and clear the marker for explicit releases.
- Start the daemon updater only for a marked stable release whose binary supports `pid-update-loop`. Existing installs without a marker require a new `latest` installation to enable automatic updates.
- Recheck the selected release under the install lock so an in-flight update cannot overwrite a new pin, including installer calls from older updaters. Recheck selection before restarting app-server or replacing the updater.
- Cancel Unix installer process groups and clean up their owned fallback locks when the updater stops.
## Testing
Add coverage for channel markers, explicit pins of the current latest version, older updater guards, updater command support, and Unix installer cancellation with child-process and lock cleanup.
GitOrigin-RevId: 4d275237bd77d896bf64dc1b85a5bca3608142c7
## Why
Unreaped zombies still pass `kill(pid, 0)` and retain their start time, so exited app-server and updater processes can appear active.
## What changed
Read process state alongside start time with `ps` and treat zombies as inactive. When the start time matches the PID record, attempt to reap the process with nonblocking `waitpid`.
## Testing
Add a Unix regression test verifying that an exited, unreaped updater is reported inactive and reaped.
GitOrigin-RevId: 55f1cd26dbb31b5835bea76591023817f1bc10b5
## What changed
Route managed Windows app-server shutdown through `/daemon/shutdown` on the local control socket. Require the server's PID and acknowledge it before triggering shutdown through the existing drain logic. Enable the endpoint only for managed Windows launches via `CODEX_DAEMON_SHUTDOWN_SOCKET`.
Watch running-turn changes whenever shutdown is requested so socket-triggered shutdown can finish draining. Keep the updater's file-based shutdown mechanism and retain forced termination as the manager's timeout fallback.
## Testing
Add a transport test covering rejection of unmanaged shutdown requests and mismatched PIDs, plus acknowledgment before emitting the shutdown event.
GitOrigin-RevId: 3e95dc1914f61e8a131f9b6fd56b6c63688d1744
## Why
The managed app-server daemon and automatic TUI attachment were limited to
Unix, so Windows users could not share a background server across Codex
sessions.
## What changed
- Enable daemon lifecycle commands, `codex agents` startup, and AF_UNIX daemon
discovery on Windows.
- Require Windows daemons to start non-elevated and verify the discovered
socket directory and peer before connecting.
- Preflight detached process support, preserve path-based environment settings,
and keep daemon processes out of the launching project's working directory.
- Fall back to an embedded server when an implicitly discovered daemon cannot
connect, while preserving errors for explicit remote endpoints and bypassing
daemon reuse when `CODEX_EXEC_SERVER_URL` is set.
## Testing
Add coverage for Windows launch restrictions and socket validation, implicit
connection fallback, executor selection, daemon discovery, and the agents
dashboard startup result.
GitOrigin-RevId: e7fd63cf8690bcca8b5155266416f31f2f792aa2
## What changed
- Run the daemon update loop on Windows using the non-interactive PowerShell installer.
- Restart the managed app server after updates and hand updater ownership to a changed managed executable through a readiness handshake.
- Contain installer descendants in a Windows job while allowing app-server and successor updater processes to break away.
- Preserve or restore PID ownership when successor startup fails, without terminating a process that reused the PID.
## Testing
- Cover non-interactive installer success and script failure on Windows.
- Cover updater handoff, readiness, rollback, inaccessible processes, and PID reuse.
GitOrigin-RevId: 5178c01124b4dd86b507b53f5093ec9a9d48e12c
## Why
The PID-managed app-server lifecycle previously supported Unix only, leaving Windows unable to start and stop the managed daemon.
## What changed
- Launch the Windows daemon as a detached process and fail clearly when the host Job Object prevents detachment.
- Add Windows file locking and process creation-time checks so stale or reused PIDs cannot cause an unrelated process to be terminated.
- Request graceful shutdown through a shutdown file, then terminate the verified process after the grace period.
- Prepare private daemon state directories consistently and pin the executable path across installer junction updates.
## Testing
Add Windows tests for process-query permissions, reused and inaccessible PIDs, and stale-record cleanup.
GitOrigin-RevId: 5ea579a7c3dc8bb6122ec3a02513836ccaacc41c
## What changed
Move Unix detached-process launch and PID publication from `pid.rs` into
`pid_start.rs`, keeping PID reservation and lifecycle behavior unchanged.
GitOrigin-RevId: acacb33953a66adc15377294ccc46d0677cc61c4
## What changed
- Prefer the managed executable under `packages/standalone/current/bin` when it exists.
- Fall back to the legacy `packages/standalone/current` executable layout.
- Preserve platform-specific missing-install paths so launch validation and lifecycle commands continue to behave as expected.
## Testing
- Add a path-selection test covering missing, legacy, and packaged installs.
GitOrigin-RevId: 4c0d066257e9984a35e3b95dd83c768d9ce69431
## Why
The PID-managed daemon updater downloaded the standalone installer directly,
bypassing Codex's configured outbound proxy policy.
## What changed
- Build the updater's HTTP client from the effective Codex configuration so
`features.respect_system_proxy` also applies to installer downloads.
- Use the route-aware client pool for the installer request.
- Warn and fall back to the default `reqwest` proxy behavior when configuration
cannot be loaded, allowing updates to continue.
## Testing
Added tests for proxy-policy selection, configuration-load fallback, exact
installer URL usage, byte preservation, and non-success HTTP responses.
GitOrigin-RevId: 559668eb40314d43afa6512da66e59e32cc1b93c
## What changed
- Remove unused APIs and test helpers across the Rust workspace.
- Route Linux sandbox test setup through the shared exec request path.
- Drop dependencies that became unnecessary after the cleanup.
GitOrigin-RevId: 48fd9b2b1575bad7add0819786b4d8ec88d8486f
## Why
An app-server child started by a previous updater can remain as a zombie after
termination. Its PID then still appears active, causing daemon shutdown to wait
until its timeout instead of removing the stale PID file.
## What changed
- Poll `waitpid` with `WNOHANG` while waiting for a PID-managed process to stop.
- Check process state before enforcing the stop deadline so an exit at the
deadline can still be observed and cleaned up.
## Testing
Added a regression test that stops an untracked child and verifies that shutdown
finishes promptly and removes its PID file.
GitOrigin-RevId: b203cf860e4207716a6cfc36015f8ee77918d13a
## Why
Users who run Codex remote control through daemon mode can keep the
daemon running, but they do not have a CLI path to mint the short-lived
manual pairing code needed to connect another device. Without this
command, they need to speak app-server JSON-RPC directly.
Related: #25675
## What Changed
- Added `codex remote-control pair`, which connects to the existing
daemon control socket and calls `remoteControl/pairing/start` with
`manualCode: true`.
- Kept the command non-lifecycle-mutating: it does not start, enable, or
restart the daemon.
- Human output labels the manual code as `Pairing code: ...`; `--json`
preserves the full pairing response.
- Added daemon socket-client, CLI formatting, and parser coverage.
## Verification
- `remote_control_client::tests::start_pairing_requests_manual_code`
verifies the daemon client sends `{ "manualCode": true }` and parses the
complete response.
-
`remote_control_cmd::tests::remote_control_pairing_human_output_labels_the_manual_code`
verifies the human-facing output.
## Why
Remote-control runtime enablement and persisted enrollment preference
were represented by separate flags. That made startup rehydration, RPC
persistence, and new-enrollment seeding race with one another, and it
did not cleanly distinguish runtime-only CLI or daemon starts from
durable app-server RPC changes.
## What Changed
- Replace the parallel enablement, seed, and rehydration flags with one
transport-owned `RemoteControlDesiredState`.
- Add nullable enrollment-scoped persistence and preserve existing
preferences during enrollment upserts.
- Rehydrate plain startup only after auth and client scope resolve,
without overwriting a concurrent RPC transition.
- Make ordinary `remoteControl/enable` and `remoteControl/disable`
durable while retaining `ephemeral: true` for runtime-only callers.
- Have the daemon explicitly request ephemeral enablement and regenerate
the app-server schemas.
## Verification
- Covered migration and `NULL`/`0`/`1` persistence round trips.
- Covered plain-start rehydration and runtime-only versus durable
enrollment seeding.
- Covered durable enable, durable disable, and ephemeral enable through
app-server RPC.
- Covered the daemon's exact `{ "ephemeral": true }` request payload.
Related issue: N/A (internal remote-control persistence architecture
change).
## Why
We are seeing cases where users have an old background app-server still
running. `codex doctor` already reports background server state, but
without the running app-server version it is harder to diagnose
behaviors that depend on the daemon build.
## What changed
- Reused the app-server daemon's passive initialize probe through a
narrow `probe_app_server_version` helper.
- Updated the `codex doctor` Background Server section to report
`app-server version: <version>` when the socket is reachable.
- Preserved the not-running OK behavior and report `app-server version:
unavailable (<short error>)` when a socket exists but the passive probe
fails.
## Description
This PR makes `codex remote-control` behave like a foreground CLI
command by default. Running it now starts remote control, waits for
readiness, prints a clear status message with the machine name, and
stays alive until Ctrl-C.
Users who want daemon behavior can use `codex remote-control start`, and
`codex remote-control stop` now prints concise human-readable output.
`--json` remains available for scripts.
Implementation-wise, this now verifies the real app-server state instead
of just assuming startup worked. The CLI starts or connects to
app-server, probes its control socket, calls the `remoteControl/enable`
API, and waits for the remote-control status response/notification
before printing success.
For daemon mode, `codex remote-control start` also reports which managed
app-server binary was used, including its path and best-effort `codex
--version`, so failures are easier to diagnose.
## Examples
Example output:
```
> codex remote-control
Starting app-server with remote control enabled...
This machine is available for remote control as com-97826.
Press Ctrl-C to stop.
```
Error case using daemon (currently expected based on our publicly
released CLI version):
```
> ./target/debug/codex remote-control start
Starting app-server daemon with remote control enabled...
Error: app server did not become ready on /Users/owen/.codex/app-server-control/app-server-control.sock
Daemon used app-server:
path: /Users/owen/.codex/packages/standalone/current/codex
version: 0.130.0
Managed app-server stderr (/Users/owen/.codex/app-server-daemon/app-server.stderr.log):
error: unexpected argument '--remote-control' found
Usage: codex app-server [OPTIONS] [COMMAND]
For more information, try '--help'.
Caused by:
0: failed to connect to /Users/owen/.codex/app-server-control/app-server-control.sock
1: No such file or directory (os error 2)
```
## What changed
- `codex remote-control` now runs remote control in the foreground and
prints a Ctrl-C stop hint.
- `codex remote-control start` starts the daemon and waits for remote
control readiness before reporting success.
- `codex remote-control stop` reports stopped/not-running status in
plain language.
- Startup failures now include recent managed app-server stderr to make
daemon issues easier to diagnose.
- Added coverage for CLI output, readiness waiting, foreground shutdown,
and stderr log tailing.
## Why
reapplies https://github.com/openai/codex/pull/22386 which was
previously reverted
Also, introduce `remoteControl/enable` and `remoteControl/disable`
app-server APIs to toggle on/off remote control at runtime for a given
running app-server instance.
## What Changed
- Adds experimental v2 RPCs:
- `remoteControl/enable`
- `remoteControl/disable`
- Adds `RemoteControlRequestProcessor` and routes the new RPCs through
it instead of `ConfigRequestProcessor`.
- Adds named `RemoteControlHandle::enable`, `disable`, and `status`
methods.
- Makes `remoteControl/enable` return an error when sqlite state DB is
unavailable, while keeping enrollment/websocket failures as async status
updates.
- Adds `AppServerRuntimeOptions.remote_control_enabled` and hidden
`--remote-control` flags for `codex app-server` and `codex-app-server`.
- Updates managed daemon startup to use `codex app-server
--remote-control --listen unix://`.
- Marks `Feature::RemoteControl` as removed and ignores
`[features].remote_control`.
- Updates app-server README entries for the new remote-control methods.
## Why
`codex remote-control` manages the app-server daemon with
`remote_control` enabled, but it previously only exposed an implicit
start path. Once started, there was no obvious top-level
`remote-control` command for stopping the daemon; users had to know
about the lower-level `codex app-server daemon stop` command.
The startup failure for missing managed installs was also ambiguous.
`codex remote-control` and daemon bootstrap require the standalone Codex
install under `CODEX_HOME/packages/standalone/current/codex`, but the
old error only said to install Codex first, which is unclear when
another `codex` binary is already on PATH. Now we add an explicit
instruction for how to get the standalone Codex install.
## What changed
- Converts `codex remote-control` into a command group while preserving
bare `codex remote-control` as the existing start behavior.
- Adds `codex remote-control start` as the explicit start path.
- Adds `codex remote-control stop`, which maps to app-server daemon
stop.
- Updates the shared daemon managed-install error to name the missing
standalone path, explain why that install is required, provide the
installer command, and tell users to rerun the command they just tried.
## Verification
- `cargo test -p codex-app-server-daemon`
- `cargo test -p codex-cli`
- `./target/debug/codex remote-control --help`
## Why
`remote_control` can appear in `config.toml`, CLI feature overrides, and
the app-server config APIs. Before this PR, app-server startup treated
`config.features.enabled(Feature::RemoteControl)` as the signal to start
remote control ([base
code](5e3ee5eddf/codex-rs/app-server/src/lib.rs (L678-L680))).
That meant a user with:
```toml
[features]
remote_control = true
```
would accidentally opt every app-server process into remote control.
Remote-control startup should instead be a per-process launch decision
made by CLI flags.
## What Changed
- Marks `Feature::RemoteControl` as `Stage::Removed`, keeping
`remote_control` as a known compatibility key while making it
config-inert.
- Adds a hidden `--remote-control` process flag to `codex app-server`
and standalone `codex-app-server`.
- Plumbs that flag through
`AppServerRuntimeOptions.remote_control_enabled` and makes app-server
startup use only that runtime option to decide whether to start remote
control.
- Removes the app-server config mutation hook that reloaded config and
toggled remote control at runtime.
- Updates managed daemon spawning to use `codex app-server
--remote-control --listen unix://` instead of `--enable remote_control`.
Config APIs can still list, read, write, and set `remote_control`; those
operations just no longer affect remote-control process enrollment.
## Why
Update `codex remote-control` to use the new app server daemon commands
instead.
- if the updater loop is not running, bootstrap the daemon with remote
control enabled (`codex app-server daemon bootstrap --remote-control`)
- otherwise, enable the persisted remote-control setting and start the
daemon normally
## 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.
