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:

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