Sinds versie 0.157.0 start de Codex CLI automatisch een persistente achtergronddaemon die ongevraagd platformpakketten kopieert en zichzelf elk uur updatet. Dit gedrag veroorzaakt technische problemen, zoals het bevriezen van omgevingsvariabelen en conflicten met pakketbeheerders.
Gebruikers en critici bestempelen dit gedrag als 'malware-achtig' vanwege de ondoorzichtigheid en de impact op het systeem. Er wordt voorgesteld om daemonautostart standaard op false te zetten (opt-in), de daemon te stoppen bij het afsluiten van de laatste client, en het zelf-updatemechanisme uit te schakelen bij installaties via pakketbeheerders. Voor gebruikers die dit nu willen stopzetten, wordt een specifieke workaround met CLI-commando's en het verwijderen van bestanden geboden.
CLI: maak daemonautostart opt-in — een persistente, zelf-updatende achtergronddaemon mag niet de standaard zijn
Beschrijving van het probleem
Sinds versie 0.157.0 start het openen van een interactieve Codex-sessie automatisch de volgende processen:
- Persistente achtergronddaemon: Er wordt een achtergronddaemon gestart (
codex app-server --managed-daemon). Deze draait in een eigen sessie zonder TTY en blijft actief nadat alle Codex-vensters zijn gesloten (herplaatst naar PID 1), totdat codex app-server daemon stop wordt uitgevoerd of het systeem wordt herstart.
- Kopiëren van platformpakketten: Het volledige platformpakket (circa 374 MB, inclusief
codex, codex-code-mode-host en gebundelde bwrap/zsh/rg) wordt gekopieerd naar ~/.codex/packages/app-server-daemon/releases/<versie>/. De daemon wordt vanuit deze kopie uitgevoerd, waardoor de versie van de backend losgekoppeld wordt van de versie van de CLI die via een pakketbeheerder is geïnstalleerd.
- Automatische updater: Er wordt een losgekoppelde updater gestart (
codex app-server daemon pid-update-loop) die vijf minuten na start en daarna elk uur controleert op updates. Nieuwe releases worden gedownload en de backend wordt herstart, wat actieve beurten kan beëindigen (na een drain-budget van 60 seconden).
- Bevriezen van de omgeving: De omgevingsvariabelen van de sessie die de daemon start, worden vastgepind. Dit veroorzaakt problemen wanneer latere sessies andere variabelen (zoals
HTTPS_PROXY) gebruiken, omdat de daemon de variabelen van de eerste sessie behoudt. Daarnaast ontvangen hooks in --remote modus de werkmap (cwd) van de daemon in plaats van die van de huidige sessie, en kunnen hooks die door de app-server daemon worden gestart de client-terminal niet identificeren.
Voor een CLI is het meest logische standaardgedrag dat de backend start en stopt met het venster, de geïnstalleerde binary gebruikt en zichzelf niet ongevraagd op de achtergrond bijwerkt. Een gedeelde, zelf-updatende daemon is zinvol voor Remote Control of de desktop-app, maar zou voor de CLI expliciet door de gebruiker geactiveerd moeten worden via codex app-server daemon start / bootstrap.
Voorgestelde verbeteringen
Indien de functie standaard ingeschakeld blijft, worden de volgende aanpassingen voorgesteld:
- Sluit een automatisch gestarte daemon zodra de laatste client wordt losgekoppeld.
- Voorkom het kopiëren en zelf-updaten wanneer de CLI is geïnstalleerd via een pakketbeheerder (zoals npm, brew of pacman); voer in dat geval de geïnstalleerde binary uit.
Tijdelijke workaround
Om de automatische daemon uit te schakelen, kan de volgende procedure worden gebruikt:
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop' # De updater wordt niet gestopt door `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon
Wanneer deze vlag is uitgeschakeld, start een nieuwe TUI-sessie geen daemon meer op.
Feedback uit de community
Gebruikerservaringen
Verschillende gebruikers melden dat de CLI onbruikbaar is geworden door dit gedrag, met name op Windows 10 LTSC. Het instellen van daemonautostart = false in het config.toml bestand lost het probleem op. Er wordt gesuggereerd om automatisch terug te vallen op de lokale modus wanneer de opstart van de daemon wordt geblokkeerd door rechtenbeperkingen (elevation), in plaats van dat de gebruiker --no-daemon moet gebruiken.
Beveiliging en integriteit
Er is kritiek op de scheiding tussen de identiteit van de geïnstalleerde CLI en de identiteit van de uitvoerende daemon. Zodra de CLI zichzelf kopieert naar een beheerde release-map en een updater deze kopie kan vervangen, is het proces dat de beurt bedient niet noodzakelijkerwijs het artefact dat de gebruiker expliciet heeft geïnstalleerd.
Er wordt voorgesteld om een "execution receipt" (uitvoeringsbewijs) te introduceren voor elke client-koppeling, bestaande uit:
clientcliversiondaemonbinarydigestdaemon_generationupdater_stateinheritedenvironmentgeneration
Overige kritiek
- Omgevingsvariabelen: Er zijn meldingen dat de daemon omgevingsvariabelen lekt van de eerste map waarin Codex werd uitgevoerd. Dit verstoort workflows die gebruikmaken van gemeenschappelijke variabelen zoals
GH_TOKEN in verschillende directories.
- Documentatie: De mogelijkheid om de functie uit te schakelen is onzichtbaar in de officiële configuratiereferentie. De release notes van versie 0.157.0 vermelden de wijziging slechts summier, zonder melding te maken van het persistente proces, de kopie van het pakket of de uurlijkse updater.
- Algemeen: Sommige gebruikers bestempelen dit gedrag als "malware-achtig" vanwege de ongevraagde installatie van processen op de achtergrond en de toegang tot het bestandssysteem.
CLI: maak daemonautostart opt-in — een persistente, zelf-updatende achtergronddaemon mag niet de standaard zijn
Beschrijving van het probleem
Sinds versie 0.157.0 start het openen van een interactieve Codex-sessie automatisch de volgende processen:
- Persistente achtergronddaemon: Er wordt een achtergronddaemon gestart (
codex app-server --managed-daemon). Deze draait in een eigen sessie zonder TTY en blijft actief nadat alle Codex-vensters zijn gesloten (herplaatst naar PID 1), totdat codex app-server daemon stop wordt uitgevoerd of het systeem wordt herstart.
- Kopiëren van platformpakketten: Het volledige platformpakket (circa 374 MB, inclusief
codex, codex-code-mode-host en gebundelde bwrap/zsh/rg) wordt gekopieerd naar ~/.codex/packages/app-server-daemon/releases/<versie>/. De daemon wordt vanuit deze kopie uitgevoerd, waardoor de versie van de backend losgekoppeld wordt van de versie van de CLI die via een pakketbeheerder is geïnstalleerd.
- Automatische updater: Er wordt een losgekoppelde updater gestart (
codex app-server daemon pid-update-loop) die vijf minuten na start en daarna elk uur controleert op updates. Nieuwe releases worden gedownload en de backend wordt herstart, wat actieve beurten kan beëindigen (na een drain-budget van 60 seconden).
- Bevriezen van de omgeving: De omgevingsvariabelen van de sessie die de daemon start, worden vastgepind. Dit veroorzaakt problemen wanneer latere sessies andere variabelen (zoals
HTTPS_PROXY) gebruiken, omdat de daemon de variabelen van de eerste sessie behoudt. Daarnaast ontvangen hooks in --remote modus de werkmap (cwd) van de daemon in plaats van die van de huidige sessie, en kunnen hooks die door de app-server daemon worden gestart de client-terminal niet identificeren.
Voor een CLI is het meest logische standaardgedrag dat de backend start en stopt met het venster, de geïnstalleerde binary gebruikt en zichzelf niet ongevraagd op de achtergrond bijwerkt. Een gedeelde, zelf-updatende daemon is zinvol voor Remote Control of de desktop-app, maar zou voor de CLI expliciet door de gebruiker geactiveerd moeten worden via codex app-server daemon start / bootstrap.
Voorgestelde verbeteringen
Indien de functie standaard ingeschakeld blijft, worden de volgende aanpassingen voorgesteld:
- Sluit een automatisch gestarte daemon zodra de laatste client wordt losgekoppeld.
- Voorkom het kopiëren en zelf-updaten wanneer de CLI is geïnstalleerd via een pakketbeheerder (zoals npm, brew of pacman); voer in dat geval de geïnstalleerde binary uit.
Tijdelijke workaround
Om de automatische daemon uit te schakelen, kan de volgende procedure worden gebruikt:
codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop' # De updater wordt niet gestopt door `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon
Wanneer deze vlag is uitgeschakeld, start een nieuwe TUI-sessie geen daemon meer op.
Feedback uit de community
Gebruikerservaringen
Verschillende gebruikers melden dat de CLI onbruikbaar is geworden door dit gedrag, met name op Windows 10 LTSC. Het instellen van daemonautostart = false in het config.toml bestand lost het probleem op. Er wordt gesuggereerd om automatisch terug te vallen op de lokale modus wanneer de opstart van de daemon wordt geblokkeerd door rechtenbeperkingen (elevation), in plaats van dat de gebruiker --no-daemon moet gebruiken.
Beveiliging en integriteit
Er is kritiek op de scheiding tussen de identiteit van de geïnstalleerde CLI en de identiteit van de uitvoerende daemon. Zodra de CLI zichzelf kopieert naar een beheerde release-map en een updater deze kopie kan vervangen, is het proces dat de beurt bedient niet noodzakelijkerwijs het artefact dat de gebruiker expliciet heeft geïnstalleerd.
Er wordt voorgesteld om een "execution receipt" (uitvoeringsbewijs) te introduceren voor elke client-koppeling, bestaande uit:
clientcliversiondaemonbinarydigestdaemon_generationupdater_stateinheritedenvironmentgeneration
Overige kritiek
- Omgevingsvariabelen: Er zijn meldingen dat de daemon omgevingsvariabelen lekt van de eerste map waarin Codex werd uitgevoerd. Dit verstoort workflows die gebruikmaken van gemeenschappelijke variabelen zoals
GH_TOKEN in verschillende directories.
- Documentatie: De mogelijkheid om de functie uit te schakelen is onzichtbaar in de officiële configuratiereferentie. De release notes van versie 0.157.0 vermelden de wijziging slechts summier, zonder melding te maken van het persistente proces, de kopie van het pakket of de uurlijkse updater.
- Algemeen: Sommige gebruikers bestempelen dit gedrag als "malware-achtig" vanwege de ongevraagde installatie van processen op de achtergrond en de toegang tot het bestandssysteem.
Groetjes,