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

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:

Observe remote codex app-server --listen unix:// hot at about 60-70% CPU.
Inspect ~/.codex/logs_2.sqlite and find ambient synthetic UserInput submissions as above.
Force-quit Windows Codex Desktop.
Kill the remote codex app-server --listen unix:// listener.
Let the remote listener relaunch without Windows Desktop connected.
No new ambient synthetic submissions appeared; remote CPU dropped back near idle.
Relaunch Windows Codex Desktop.
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

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

Codex Desktop ambient_suggestions consumes ~70k tokens in the background #30390
[Windows Desktop] Background ambient/home suggestions consume user quota without explicit action #29380
Windows Codex 26.623.5546.0 still persists high-frequency TRACE logs to logs_2.sqlite WAL #30405
Codex App writes high-volume TRACE logs to logs_2.sqlite despite RUST_LOG=warn #30236
Windows Codex app continuously writes high-volume TRACE websocket logs to ~/.codex/logs_2.sqlite despite RUST_LOG=warn #29463

Powered by Codex Action

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.

Navigation Menu

Repository navigation

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

Summary

Environment

Observed ambient submissions

Remote impact

Isolation test

Expected behavior

Actual behavior

Related existing issues

Environment (sanitized)

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

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

3. What's churning

Ask

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Summary

Environment

Observed ambient submissions

Remote impact

Isolation test

Expected behavior

Actual behavior

Related existing issues

Activity

github-actions commented on Jun 29, 2026

cyber-ayi commented on Jul 8, 2026

Environment (sanitized)

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

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

3. What's churning

Ask

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions