›_ Codex Issues
Codex Issues / #30606

Windows Desktop ambient suggestions over SSH remote can drive remote app-server SQLite CPU/IO churn

Open 💬 2 comments Opened Jun 29, 2026 by maxschachere
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

In a Windows Codex Desktop -> SSH remote Linux workflow, opening/relaunching Codex Desktop appears to inject hidden ambient_suggestions turns into the remote codex app-server --listen unix:// listener. On the remote host, those background turns can drive sustained CPU and disk write pressure because the app-server persists high-volume TRACE websocket/SSE logs into ~/.codex/logs_2.sqlite while also pruning the table.

This is distinct from ordinary visible user turns: the ambient logical thread IDs did not appear as normal visible threads in the remote state_*.sqlite thread table.

Environment

Sanitized environment:

  • Client: Codex Desktop on Windows, version 26.623.42026
  • Remote: Linux arm64 host reached through Codex Desktop SSH remote
  • Remote Codex CLI/app-server observed at 0.142.3
  • Remote listener process: codex app-server --listen unix://
  • Remote app-server protocol logs identify the client as app_server.client_name="Codex Desktop"

No private hostnames, IP addresses, usernames, exact workspace paths, or private project contents are included in this report.

Observed ambient submissions

On the remote host, ~/.codex/logs_2.sqlite contained hidden synthetic UserInput submissions with prompt text matching the Desktop ambient suggestion flow:

Generate 0 to 3 hyperpersonalized suggestions...

followed a few minutes later by the safety pass:

You are an expert at upholding safety and compliance standards for Codex ambient suggestions...

In two observed ambient pairs, the safety pass followed the generation pass after about 3.5-4 minutes.

Remote impact

During the bad state, the remote listener process became hot:

codex app-server --listen unix://

Representative measurements from the remote host:

  • app-server process: about 60-70% CPU
  • hot OS threads: sqlx-sqlite-worker and tokio-rt-worker
  • ~/.codex/logs_2.sqlite retained row count stayed roughly flat while id advanced by thousands/sec, consistent with insert/prune churn
  • one 5-second sample showed about 33k new log IDs and roughly 160 MB written by the app-server process
  • recent retained rows were mostly TRACE websocket/SSE noise, including targets/messages like:
  • codex_api::sse::responses
  • tokio-tungstenite
  • Received message
  • Parsed headers
  • WouldBlock

So the visible symptom on the remote host was not only background token use; it was sustained CPU and disk write pressure in the remote app-server SQLite logging path.

Isolation test

Steps that reproduced/isolated the behavior:

  1. Observe remote codex app-server --listen unix:// hot at about 60-70% CPU.
  2. Inspect ~/.codex/logs_2.sqlite and find ambient synthetic UserInput submissions as above.
  3. Force-quit Windows Codex Desktop.
  4. Kill the remote codex app-server --listen unix:// listener.
  5. Let the remote listener relaunch without Windows Desktop connected.
  6. No new ambient synthetic submissions appeared; remote CPU dropped back near idle.
  7. Relaunch Windows Codex Desktop.
  8. The ambient suggestions returned and the remote app-server CPU/SQLite churn returned.

Expected behavior

  • Desktop ambient/home suggestions should not silently start expensive background model turns on an SSH remote host, or should be clearly user-controlled and disabled by default for remote workspaces.
  • If ambient suggestions are enabled, they should not cause sustained remote app-server CPU/IO churn.
  • TRACE websocket/SSE traffic from these background turns should not be persisted into SQLite at high volume while pruning on every batch.

Actual behavior

Opening/relaunching Windows Codex Desktop can cause hidden ambient suggestion turns to run through the remote SSH app-server. On the remote Linux host this can create high-volume TRACE logging into logs_2.sqlite, causing sustained SQLite worker CPU and disk writes.

Related existing issues

This appears related to both categories below, but the combined SSH-remote reproduction seems worth tracking separately:

  • Desktop ambient suggestions / background generation, e.g. #30390, #30170, #25302
  • logs_2.sqlite TRACE/logging churn, e.g. #30431, #30405, #30236, #29799, #29674

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #30390
  • #29380
  • #30405
  • #30236
  • #29463

Powered by Codex Action

cyber-ayi · 1 month ago

Reproduced on 0.143.0-alpha.39, with additional evidence — the documented client-side ambient disable switches do NOT stop the remote churn

Confirming this on a Codex Desktop → SSH-remote Linux setup, and adding a few data points that may help isolate it. The most important: the client-side disable switches have no effect on the remote app-server load.

Environment (sanitized)

  • Client: Codex Desktop over SSH remote
  • Remote: self-hosted Linux x86_64, consumer NVMe root
  • Remote codex app-server --listen unix://; cliVersion / appServerVersion = 0.143.0-alpha.39
  • Remote DB: ~/.codex/logs_2.sqlite (WAL)

Note: 0.143.0-alpha.39 already contains #29599, so this is not the TRACE flood — see §3.

1. Controlled experiment — the churn is 100% driven by the Desktop connection

Same app-server PID throughout (no restart); the only variable is whether Desktop is connected. Sampled from an independent local shell on the remote (not through the Codex RC channel), touching only /proc and read-only SQLite, so the sampling itself injects no RC load.

| State | app-server CPU | net write | logs rowid churn |
|---|---|---|---|
| Desktop connected | ~50–55% | ~0.5–0.9 MB/s | ~47–60 rows/s, net rows +0 |
| Desktop disconnected | 0% | 0 | 0 |

The instant Desktop disconnects, the same process drops to true idle (0% CPU, no writes, no busy worker threads). Reconnect → the churn returns. This rules out a remote-side leak/degradation: the load is entirely the Desktop-injected ambient turns this issue describes.

2. Client-side disable switches have NO effect (key finding)

Following the documented approach, with Desktop fully quit (so .codex-global-state.json isn't rewritten on exit), both flags were set in both files:

  • ~/.codex/config.toml → [desktop] ambient-suggestions-enabled = false
  • ~/.codex/.codex-global-state.json → ambient-suggestions-enabled = false, ambient-suggestions-background-refresh = false

After relaunching Desktop, the remote churn is unchanged — steady ~50% CPU across a 6×15s time series (i.e. sustained, not a reconnect catch-up burst):

seg1: CPU=50.0%   57.3 rows/s   877 kB/s
seg2: CPU=50.0%   47.2 rows/s   759 kB/s
seg3: CPU=50.0%   50.2 rows/s   754 kB/s
seg4: CPU=50.0%   49.6 rows/s   780 kB/s
seg5: CPU=50.0%   52.2 rows/s   784 kB/s
seg6: CPU=50.0%   49.4 rows/s   783 kB/s

So on the SSH-remote path, ambient-suggestions-enabled / -background-refresh do not gate the ambient turns that reach the remote app-server. The only thing that stops it is disconnecting Desktop entirely.

3. What's churning

Recent rows are 100% codex_app_server::request_processors::process_exec_processor at DEBUG level, with max_rowid advancing ~50/s while the net row count stays flat (insert-then-delete). CPU hotspots are multiple tokio-rt-worker threads (~9–20% each); sqlx-sqlite-worker is <2% — so the cost is async/turn handling, not the SQLite writer. A TRACE/insert trigger reduces disk writes but cannot touch the CPU.

Ask

Is there any supported way to refuse or gate ambient / ambient_suggestions turns on the remote app-server side (config or env), independent of the Desktop client? On a headless SSH-remote host the client switches are the only documented lever, and per §2 they don't apply here. Even a remote --no-ambient / config flag would let remote users opt out until client-side gating is fixed.

Happy to provide more metadata-only samples.