Commit Graph

6 Commits

Author SHA1 Message Date
Eric Traut
769a6a5bcd Record the launched app-server executable identity in PID files (#43552)
## 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
2026-09-07 18:52:37 +00:00
Eric Traut
455318c202 Replace Windows app-server shutdown files with socket requests (#43308)
## 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
2026-09-07 00:00:23 +00:00
Eric Traut
715294448f Support managed app-server lifecycle on Windows (#42381)
## 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
2026-09-02 23:10:08 +00:00
Michael Bolin
99eb575649 Honor system proxy settings in the daemon updater (#34495)
## 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
2026-07-21 08:50:21 +00:00
Ruslan Nigmatullin
e3f481da98 daemon: refresh updater after validated binary rollout (#21853)
## 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
2026-05-11 12:37:10 -07:00
Ruslan Nigmatullin
0c8d42525e [daemon] Add app-server daemon lifecycle management (#20718)
## 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.
2026-05-08 16:51:16 -07:00