Prismix
Hacker News — AI on Front Page · · 7 min read

Codex CLI installs a persistent, self-updating background daemon by default

#developer-tool

Mirrored from Hacker News — AI on Front Page for archival readability. Support the source by reading on the original site.

206 pts · 122 comments on Hacker News

Like Read original ↗

CLI: make daemon_auto_start opt-in — a persistent, self-updating background daemon shouldn't be the default #48195

Copy link
Copy link
Open
Labels
CLIIssues related to the Codex CLIIssues related to the Codex CLIapp-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfacesenhancementNew feature or requestNew feature or request

Description

@Yihua-Liu-1997
Issue body actions

What variant of Codex are you using?

CLI — 0.157.0, installed via npm install -g @openai/codex, Linux (WSL2)

What feature would you like to see?

Please make daemon_auto_start opt-in (default false) for the CLI, or at least ask once before turning it on.

Since 0.157.0, just opening an interactive codex session:

  1. Starts a persistent background daemon (codex app-server --managed-daemon). It runs in its own session with no TTY and keeps running after every Codex window is closed (reparented to PID 1) until codex app-server daemon stop or a reboot.
  2. Copies the whole platform package (~374 MB: codex, codex-code-mode-host, bundled bwrap/zsh/rg) into ~/.codex/packages/app-server-daemon/releases/<version>/ — byte-identical to what npm had just installed — and runs the daemon from that copy. From then on the backend's version is decoupled from the CLI version I installed with my package manager.
  3. Starts a detached updater (codex app-server daemon pid-update-loop) that checks for updates 5 minutes after start and then hourly, downloads new releases and restarts the backend (which can kill active turns, see app-server daemon: auto-update force-kills active turns after a 60s drain budget, and cannot be disabled #40969).
  4. Pins the environment of whichever session happened to start it. I launch Codex through a wrapper that sets HTTPS_PROXY per invocation; the daemon keeps the first session's proxy variables and its outbound connections go through that proxy, whatever later sessions are launched with. Hooks in --remote mode receive the daemon's cwd, not the session's #42457 and Hooks spawned by the app-server daemon cannot identify the client terminal, breaking terminal-targeting hooks #37537 (daemon cwd / terminal instead of the session's) look like the same root cause.

For a CLI, the least surprising default is that the backend lives and dies with the window, runs the binary I installed, and doesn't update itself in the background. A shared, self-updating daemon makes sense for Remote Control / the desktop app, so it would be fine to enable it there, or when the user explicitly runs codex app-server daemon start / bootstrap.

If it stays on by default, please at least:

Additional information

Bug found while turning it off: codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running (still alive 70 s later, had to kill it manually).

Workaround I'm using:

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'   # not stopped by `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon

With the flag off, a new TUI session no longer spawns a daemon.

Related: #40969, #41188, #46468, #48050, #42457, #37537

Reactions are currently unavailable

Activity

  1. added
    enhancementNew feature or requestNew feature or request
    CLIIssues related to the Codex CLIIssues related to the Codex CLI
    app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces
    on Sep 25, 2026

  2. megahall commented on Sep 25, 2026

    @megahall
    More actions

    @Yihua-Liu-1997 thanks for reporting this, I hit it myself... stuff should not be creating mystery servers and processes all of a sudden on small version number bumps without giving people a heads-up...

    Reacted by tagor, Flaviu Tamas, Felipe Lopes, Josh Triplett, BigBoyDevBox, Kamil Mielnik and Mikhail

  3. kr8vka0z commented on Sep 25, 2026

    @kr8vka0z
    More actions

    agreed. the CLI is unusable until this is fixed.

    Reacted by tagor, Steven Dale, Felipe Lopes, krrr, Shaun Pedicini, Christian Hahn, BigBoyDevBox and Mikhail

  4. tagorr commented on Sep 25, 2026

    @tagorr
    More actions

    I can confirm this on Windows 10 LTSC with Codex CLI 0.157.0
    Setting daemon_auto_start = false in config.toml resolves the issue

    Two improvements would help:

    1. Automatically fall back to local mode when daemon startup is blocked by elevation, instead of requiring --no-daemon.
    2. Make daemon auto-start opt-in rather than the default.

    This would preserve the security restrictions without disrupting the normal CLI workflow.

    Reacted by BigBoyDevBox

  5. Yihua-Liu-1997 commented on Sep 26, 2026

    @Yihua-Liu-1997
    Author
    More actions

    @tagorr Indeed — both 1 and 2 would work~

    Reacted by tagor

  7. felipeelopes commented on Sep 29, 2026

    @felipeelopes
    More actions

    The Codex CLI is unusable due to this bug on Windows.

  8. zdd commented on Sep 30, 2026

    @zdd
    More actions

    This is terrible. I can't input anything on the CLI at all. You should fix this problem as soon as possible and give us 100 banked reset!

  9. aetherxeg-source commented on Oct 3, 2026

    @aetherxeg-source
    More actions

    There is a useful provenance boundary behind this request:

    installed CLI identity != daemon execution identity

    Once the CLI copies itself into a managed release directory and a background updater can replace that copy, the process that services a later turn is no longer necessarily the artifact the user explicitly installed or invoked.

    I would make the daemon expose a small execution receipt for each client attachment containing at least:

    client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation

    Then a client can distinguish:

    • same installed artifact, same daemon generation;
    • same CLI but different daemon generation;
    • daemon binary changed independently of the package-manager state;
    • daemon inherited environment from an earlier session.

    A strong regression would start the daemon under environment A, attach from environment B, update the installed CLI, and verify that the client can see exactly which daemon generation/binary/environment is authoritative for the turn rather than inferring it from the foreground CLI version.

    Related runtime behavioral-integrity work: https://github.com/AETHERXGLOBAL/execsurface

  13. laurynas-karvelis commented on Oct 12, 2026

    @laurynas-karvelis
    More actions

    Basically - a trait of malware. TBF I don't even think this was done by accident

    Reacted by tagor, Ymir and Abhiram S Sajeev
    Reacted by tagor

  14. skhaz commented on Oct 12, 2026

    @skhaz
    More actions

    +1 for disabling this

  15. tagorr commented on Oct 12, 2026

    @tagorr
    More actions

    Basically - a trait of malware. TBF I don't even think this was done by accident

    Honestly, that's exactly what it feels like.

  16. st396gt commented on Oct 12, 2026

    @st396gt
    More actions

    The part in the docs about wanting full read/write access to the entire host filesystem is why I'm running codex-cli in a hardened Raspberry Pi and ssh'ing into it.

    No daemons running that I can see, v0.160.0 from last week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIIssues related to the Codex CLIapp-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfacesenhancementNew feature or requestNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      Discussion (0)

      Sign in to join the discussion. Free account, 30 seconds — email code or GitHub.

      Sign in →

      No comments yet. Sign in and be the first to say something.

      More from Hacker News — AI on Front Page