## What changed
Make plain `codex remote-control` start or reuse the managed daemon and enable remote control when daemon auto-start is enabled and the environment is eligible. Fall back to the foreground server when no managed backend is available or Windows restricts detached launch.
Add `codex remote-control --no-daemon` to explicitly run the foreground server, and honor the top-level `--no-daemon` flag. Reject this flag with `start`, `stop`, or `pair`. Keep `--json` and launches with configuration overrides or unsupported environments on the foreground path.
GitOrigin-RevId: cb28ae3f6074993b748660972c3cb7cbf6612c2f
## Why
Some Windows policies deny in-process reparse-point mutation while allowing the system junction creator, preventing managed daemon release selection.
## What changed
Fall back to `cmd.exe` with `mklink /J` when native junction creation or retargeting returns `PermissionDenied`. Pass quoted paths through environment variables and disable delayed expansion to handle shell metacharacters.
Create the replacement junction before moving the existing `current` junction aside, and attempt to restore the previous junction if installation fails. Preserve it for recovery if restoration also fails.
## Testing
Extend the Windows junction test to cover fallback creation, native retargeting, and fallback replacement under a path containing spaces, `&`, `%`, and `!`, while verifying that no standalone CLI installation is created.
GitOrigin-RevId: 039ee850f8c788f44f08116614ca3927e3e9952f
## Why
Executable scanners can briefly hold newly staged files without delete sharing, causing the rename that publishes a managed daemon release to fail on Windows.
## What changed
Retry publication on permission-denied or sharing-violation errors at 50 ms intervals, up to 100 retries. Report the staging and release paths if publication fails.
## Testing
Add a Windows test that holds the staging directory open without delete sharing, releases the handle after a delay, and verifies that publication succeeds with the payload intact.
GitOrigin-RevId: 4fbd50934ec8937d3b440d38203a2cb7356a316d
## 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
Daemon updates discard installer stderr, leaving failed installs with only an exit status and no installer diagnostics.
## What changed
Capture the last 2 KiB of installer stderr and append it to errors when the installer exits unsuccessfully. Drain stderr concurrently and wait at most one second after failure so subprocesses holding the pipe open cannot delay error reporting indefinitely. Keep captured details within the manual update response limit, and configure PowerShell output as UTF-8 to preserve non-ASCII diagnostics.
## Testing
Add coverage for stderr tail truncation, bounded draining when a subprocess keeps stderr open, and manual update responses containing heavily escaped diagnostics. Extend the Windows installer test to check non-ASCII error text.
GitOrigin-RevId: d0da19b233006f97770d3f7f5f057e5e98fd2913
## What changed
- Centralize `windows-sys` at version `0.61.2` in the workspace and migrate dependent crates to it.
- Adapt Windows API calls to the updated handle, boolean, and type definitions. Replace custom handle owners with `OwnedHandle` and use `BorrowedHandle` where ownership stays with the caller.
- Add explicit wrappers for non-owning Windows handles passed between threads.
## Testing
Enable the MCP refresh cleanup test on Windows. Retain process handles to verify that a superseded MCP server stays alive during an in-flight call, exits after cancellation, and leaves the replacement running until shutdown.
GitOrigin-RevId: 86f53d9b300d13edff7154f4a7c32e34dacd2919
## Why
Concurrent Linux test spawns can inherit writable descriptors for executable fixtures, preventing those fixtures from being executed even after the writing test closes its descriptor.
## What changed
Replace direct executable fixture writes and copies across the Rust tests with `codex_utils_cargo_bin::write_executable` and `copy_executable`. These existing helpers complete writes and copies in separate processes on Linux.
Remove the empty temporary inode before creating fake bubblewrap executables, and stage tampered bubblewrap bytes in a separate data file before copying them into the executable fixture. Add the required test dependencies.
GitOrigin-RevId: c875c83088731a4933ef1574e8d79d8cecc12f54
## Why
The Windows shared daemon rejects elevated launches so shared clients cannot inherit administrator privileges. Local TUI sessions launched as administrator should still be able to start.
## What changed
Select embedded mode before daemon discovery or startup for elevated local Windows sessions. Show a startup warning explaining that the shared background server is disabled and that restarting Codex in a non-elevated terminal enables it. Record `elevated_windows` as the server selection reason.
## Testing
Add Windows integration coverage for elevated normal, `resume`, and `fork` launches without creating daemon directories, and verify that explicit daemon `start` and `restart` still reject elevation. Add a snapshot test for the startup warning in the warning center.
GitOrigin-RevId: 89594e86d6ee19b080dfb11553cee8676395f188
## Why
Windows processes hold their working directory open for their lifetime, and sandbox setup may broaden its ACL. Managed children should avoid pinning the launching project's directory or changing permissions on the private daemon state directory.
## What changed
Create a `workdir` subdirectory alongside the PID files and use it as the working directory for both the managed app-server and updater on Windows.
## Testing
Add a Windows regression test covering both managed children. It verifies that relative files land in `workdir`, the state directory still passes private-directory validation, and stopping each child removes its PID file.
GitOrigin-RevId: 12ca95463ff3c80899a5b1a8800fead849f48017
## Why
Detached launches truncate stderr logs, losing details from previous failures. Updater handoffs can also leave existing writers with stale offsets after truncation.
## What changed
- Record daemon lifecycle and update stages with timings, outcomes, and typed OS errors, omitting error messages and context.
- Preserve the last 256 KiB of nonempty stderr logs before truncation and use append handles to prevent gaps during handoff. Preservation failures do not block launch.
- Attach current and previous updater log tails when log inclusion is enabled for a report, with a 512 KiB total limit and legacy filename fallback. Skip missing, empty, and nonregular files.
## Testing
Add regression coverage for diagnostic error redaction, bounded log preservation, append behavior during handoff, attachment selection, and updater logs in captured report uploads.
GitOrigin-RevId: 918317022ab9dcfd1b13d676872706c77e9ffbb2
## Why
Managed daemons and updaters can outlive their launching directory. Restarts and updater replacement need to keep working after that directory is removed.
## What changed
- Share working-directory preparation between background launches and Unix updater re-execution. Fall back to the daemon state directory when the Unix working directory is missing, while retaining usable working directories and the existing Windows state-directory behavior.
- Preserve configured `CODEX_HOME` paths and valid symlink aliases, and make certificate and AWS environment paths absolute before launching children. Handle both `npm_config_cafile` and `NPM_CONFIG_CAFILE`, preserving supported home-relative values.
- Log warnings when scheduled daemon updates fail.
## Testing
Add Unix regression coverage for restarting the daemon and updater from a deleted working directory, and for updater re-execution with preserved environment paths, `CODEX_HOME` symlink aliases, and a Linux non-Unicode home path.
GitOrigin-RevId: f45aefd8ff060adc6e025badf0bb8c81f842bf88
## Why
Daemon-launched app servers should use the same analytics default as first-party clients while honoring explicit user opt-outs.
## What changed
Pass `--analytics-default-enabled` when the PID backend launches an app server, with or without remote control. Users can still disable analytics with `analytics.enabled = false` in `config.toml`.
## Testing
Update argument assertions for both remote-control modes and the daemon start/restart test to expect the analytics flag alongside launch feature overrides.
GitOrigin-RevId: 8a222a00fc56737f5fe2b0385abf59466d1a6671
## What changed
- Show a compact session header with a randomly selected greeting, preserving the greeting and blossom state from startup into the live session.
- Center a settled blossom in unused fullscreen space and replay its animation on click. Hide it while typing or when space is insufficient, and respect `tui.animations` and `tui.effects.welcome`.
- Hide startup tips in the fullscreen transcript while retaining them in terminal scrollback, and prevent hidden entries from shifting the first visible header.
- Keep the composer visible and responsive during daemon startup, routing startup diagnostics through tracing while direct lifecycle commands retain stderr output.
## Testing
Add regression tests and update snapshots for blossom placement and click replay, welcome opt-outs, greeting stability, startup transitions, tip visibility, and transcript spacing.
GitOrigin-RevId: ec7b082fbe25ced1180cad3348f5c76e48c0e92b
## Why
Windows launchers such as `cargo run` can prevent background processes from outliving them, causing automatic daemon startup to fail and blocking the CLI from opening.
## What changed
- Classify detached launch restrictions by retrying an access-denied launch probe without the job breakaway flag. Keep both probes suspended and terminate and reap successful probes.
- Use the embedded server with a visible warning when automatic startup encounters this restriction. Preserve errors for other launch failures, including inaccessible executables and elevated startup.
- Keep explicit daemon lifecycle operations failing on the restriction, with guidance to build and run `codex.exe` directly.
## Testing
Add Windows coverage for restriction classification and executable access failures, plus a CLI integration test and warning snapshot for embedded fallback under a restrictive job. The integration test also checks that elevated startup still fails and no daemon PID file is created.
GitOrigin-RevId: fc7c46e0f5f07ca0aba12b535a0e372021bdf46a
## Why
Detached Windows daemons can inherit the launcher's output pipes, leaving callers waiting for EOF after the launcher exits.
## What changed
Clear inheritance flags on the launcher's standard handles before spawning managed Windows processes. Leave the flags cleared to protect concurrent launches while preserving the child's configured stdio, and tolerate missing or already-closed handles.
## Testing
- Add a Windows regression test verifying that captured launcher output closes while the detached child remains alive and writes to its configured log.
- Give optional MCP startup grace tests more time to complete on slow runners while keeping the pending server's startup timeout longer than the turn timeout.
GitOrigin-RevId: 053e0417793db3c961e738476a05c7467978f339
## Why
A Windows breakaway launch can leave an outer Job Object attached after escaping an inner job. Job membership alone does not establish whether the daemon will be terminated, so rejecting all remaining membership can block valid launches.
## What changed
Remove the job-membership checks from the launch preflight and the spawned daemon. Keep the suspended breakaway probe to verify that launch is permitted before stopping an existing daemon, and terminate and reap the probe afterward.
## Testing
Add a Windows regression test with nested jobs that verifies the probe and daemon leave the inner job while retaining the outer job, and that daemon startup succeeds.
GitOrigin-RevId: 4c6aafd158300fa428ec398d72dc5d3411c0d8b8
## Why
The PID reservation test could race with the backend's read on Windows by deleting the PID file from its cleanup task. The guardian heartbeat snapshot and environment normalization also needed to match the current permission-context wording.
## What changed
- Release the reservation lock and let `stop()` remove the stale PID file, then assert that the file is gone.
- Update the guardian heartbeat snapshot and normalization pattern to use `The active permission profile for environment`.
GitOrigin-RevId: d9cadae0e5d36cb2e1ab0517e2d7121cf2d0715d
## 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
Automatic daemon launches could silently fall back to embedded mode when shared feature settings differed from the session's requirements. Changing those settings affects other clients, and restarting the server may interrupt active or queued work.
## What changed
- Offer interactive choices to run without the daemon, restart with the required settings, or cancel. Default to cancel and require explicit confirmation for restart.
- Allow restart only for managed daemons with a feature mismatch, then recheck compatibility once. Noninteractive required-daemon failures return an error with `--no-daemon` guidance; optional attachment retains its fallback behavior.
- Preserve saved feature overrides on startup and require confirmation before applying requested shared-feature disables, including on fresh starts.
- Merge confirmed settings under the lifecycle lock, persist changes after the old process stops, and avoid restarting when the saved overrides already match.
## Testing
Add recovery-menu snapshots and confirmation tests, compatibility tests for required and optional attachment, daemon ownership and settings-preservation tests, and CLI terminal tests for cancellation, embedded fallback, confirmed restart, and disabling shared features.
GitOrigin-RevId: d50a6cf7e476b9647237431e8fc0fc6041ed17db
## Why
Feature overrides previously forced embedded mode even when they could work with the shared daemon. A running daemon can also have different feature settings from the current invocation, including when the invocation uses defaults.
## What changed
- Allow selected Boolean feature overrides and `suppress_unstable_features_warning` in daemon mode. Keep explicit overrides that disable shared services in embedded mode.
- Pass shared-service feature overrides to newly launched daemons and persist them for restarts and updates without changing a running daemon's settings.
- Check daemon feature settings with `experimentalFeature/list` before attaching. Warn and fall back to embedded mode on mismatches, failed checks, or an incompatible code-mode host fallback policy. Skip this check for the agents overview.
- Resolve worktree configuration before daemon selection and allow worktree sessions to auto-start the daemon.
- Forward `suppress_unstable_features_warning` in thread configuration overrides.
## Testing
Add coverage for override eligibility and precedence, launch-feature persistence and reuse, and TUI fallback warnings for feature and host-policy mismatches. Extend worktree integration coverage to exercise daemon auto-start and warning suppression.
GitOrigin-RevId: 68c316f74843b1dfd8fa39bdb48bd1f649fee57f
## Why
TUI startup metrics report the selected app-server mode before a connection succeeds, which can misrepresent embedded fallback or failed startup. Daemon startup and update actions also need distinct outcome observations.
## What changed
- Record `codex.tui.start` once after the first connection attempt, using the actual mode or `unconfirmed`, and include daemon selection and auto-start tags.
- Add `codex.daemon.start` for TUI auto-start and `codex.daemon.update` for foreground CLI updates and TUI update handoffs, using existing analytics consent and identity handling.
- Report TUI handoffs as `handoff_requested` and suppress duplicate child reporting. Remove the suppression flag when spawning long-lived daemon processes.
- Tag daemon settings by enabled state and explicit presence, without exporting setting values or contents; report invalid or unreadable settings as `unknown`.
## Testing
Add coverage for analytics defaults and explicit consent overrides, unconfirmed CLI updates, settings presence, and exactly-once launch observations. Extend the worktree TUI test to check startup tags and a single update handoff observation.
GitOrigin-RevId: 176d2ee594f930033fa1ece55d4c1c9603dbbc16
## 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`
Eric Traut