Summary
Codex Desktop Remote SSH can generate sustained outbound SSH traffic of roughly 4 MB/s from the remote codex app-server proxy when the apps feature is enabled.
This is reproducible on two independent Linux SSH hosts. Disabling apps on the remote host immediately stops the traffic.
This is not normal project file transfer: strace shows the proxy receiving and forwarding large app/list / App Directory payloads containing app metadata (names, descriptions, install URLs, icon assets, etc.).
The issue still reproduces with remote Codex CLI/runtime 0.147.0.
Impact
Observed cumulative SSH traffic exceeded 240 GB over roughly a day of normal Remote SSH use.
At the reproduced steady state:
apps=true: about 119–120 MB per 30 seconds (~4 MB/s, ~14 GB/hour per remote)apps=false: traffic drops to effectively zero; one measurement was 12 bytes per 30 seconds
With multiple remote projects/hosts open, this can multiply quickly.
Environment
- Client: Codex Desktop on macOS
- Remote: Linux x86_64 over Codex Desktop Remote SSH
- Confirmed remote runtime:
codex-cli 0.147.0
- Earlier reproduction also occurred with remote runtime
0.144.1
- Reproduced on two separate Linux machines/projects
Reproduction
- Configure a Codex Desktop Remote SSH host.
- On the remote host, enable Apps:
codex features enable apps
- Restart/reopen the Remote Project so a new
codex app-server proxy starts.
- Measure the proxy's stdout character count:
PID="$(pgrep -n -f 'codex app-server proxy')"
R1=$(awk '/^wchar:/{print $2}' /proc/$PID/io)
sleep 30
R2=$(awk '/^wchar:/{print $2}' /proc/$PID/io)
echo "$((R2-R1)) bytes"Observed examples:
125002448 bytes / 30s (~119 MB)
126731714 bytes / 30s (~120 MB)
127639680 bytes / 30s (~121 MB)
- Disable Apps on the same remote:
codex features disable apps
- Restart/reopen the Remote Project and repeat the measurement.
Observed:
The SSH traffic also visibly drops immediately after disabling Apps.
strace evidence
A 10-second sample of codex app-server proxy while the issue was active showed:
client read(0): 19
client sendto(10): 18
server recvfrom(10): 5132
stdout write(1): 5132
recv_MB=9.33
stdout_MB=7.58
send_MB=0.00
The server response payload contained a large sequence of App Directory entries, including fields such as:
name
description
logoUrl
iconAssets
distributionChannel
appMetadata
installUrl
isAccessible
isEnabled
and many unrelated public directory apps (travel, productivity, developer tools, etc.). This strongly suggests the traffic is the global merged App Directory/catalog being pushed over the Remote SSH app-server connection, rather than source files or Git state.
Earlier sampling also showed the proxy writing ~49 MB in 10 seconds while /proc/<pid>/io reported zero disk reads/writes, further ruling out repeated project filesystem scanning as the primary source.
Cross-host A/B result
Host A:
apps=true -> ~119 MB / 30s
apps=false -> ~0
Host B:
apps=true -> ~120 MB / 30s
apps=false -> SSH traffic immediately drops
This makes the issue unlikely to be specific to a repository, Git root, runtime data, file count, or one Linux host/kernel.
Expected behavior
Remote SSH should not continuously retransmit the complete Apps/App Directory catalog at multi-MB/s while idle.
app/list pagination and/or app/list/updated notifications should avoid repeatedly sending the full merged directory, or the Desktop client should deduplicate/throttle catalog refreshes and updates.
Workaround
codex features disable apps
This resolves the bandwidth issue, but disables Apps/Connector integration on that remote host, so it is not an ideal long-term workaround.
Related issue
Possibly related to #34901, which reports that app/list/updated can deliver the full 2,402-app merged catalog despite a paginated app/list request. That issue focuses on a plugin-detail rendering/refetch problem; this report focuses specifically on Remote SSH sustained network transfer / bandwidth usage, reproducible across two Linux remotes and eliminated by apps=false.
Sanitized logs and additional strace samples can be provided if useful.
Summary
Codex Desktop Remote SSH can generate sustained outbound SSH traffic of roughly 4 MB/s from the remote
codex app-server proxywhen theappsfeature is enabled.This is reproducible on two independent Linux SSH hosts. Disabling
appson the remote host immediately stops the traffic.This is not normal project file transfer:
straceshows the proxy receiving and forwarding largeapp/list/ App Directory payloads containing app metadata (names, descriptions, install URLs, icon assets, etc.).The issue still reproduces with remote Codex CLI/runtime 0.147.0.
Impact
Observed cumulative SSH traffic exceeded 240 GB over roughly a day of normal Remote SSH use.
At the reproduced steady state:
apps=true: about 119–120 MB per 30 seconds (~4 MB/s, ~14 GB/hour per remote)apps=false: traffic drops to effectively zero; one measurement was 12 bytes per 30 secondsWith multiple remote projects/hosts open, this can multiply quickly.
Environment
codex-cli 0.147.00.144.1Reproduction
codex features enable appscodex app-server proxystarts.Observed examples:
Observed:
The SSH traffic also visibly drops immediately after disabling Apps.
straceevidenceA 10-second sample of
codex app-server proxywhile the issue was active showed:The server response payload contained a large sequence of App Directory entries, including fields such as:
and many unrelated public directory apps (travel, productivity, developer tools, etc.). This strongly suggests the traffic is the global merged App Directory/catalog being pushed over the Remote SSH app-server connection, rather than source files or Git state.
Earlier sampling also showed the proxy writing ~49 MB in 10 seconds while
/proc/<pid>/ioreported zero disk reads/writes, further ruling out repeated project filesystem scanning as the primary source.Cross-host A/B result
Host A:
Host B:
This makes the issue unlikely to be specific to a repository, Git root, runtime data, file count, or one Linux host/kernel.
Expected behavior
Remote SSH should not continuously retransmit the complete Apps/App Directory catalog at multi-MB/s while idle.
app/listpagination and/orapp/list/updatednotifications should avoid repeatedly sending the full merged directory, or the Desktop client should deduplicate/throttle catalog refreshes and updates.Workaround
This resolves the bandwidth issue, but disables Apps/Connector integration on that remote host, so it is not an ideal long-term workaround.
Related issue
Possibly related to #34901, which reports that
app/list/updatedcan deliver the full 2,402-app merged catalog despite a paginatedapp/listrequest. That issue focuses on a plugin-detail rendering/refetch problem; this report focuses specifically on Remote SSH sustained network transfer / bandwidth usage, reproducible across two Linux remotes and eliminated byapps=false.Sanitized logs and additional
stracesamples can be provided if useful.