Remote access performs poorly on weak networks, such as packet loss, high latency, or low bandwidth

What issue are you seeing?

Remote access becomes very difficult to use under poor network conditions, especially when connecting to hosts over SSH with high latency, packet loss, or low bandwidth.

The symptoms I often see include:

• Clicking into a session may take a very long time to load. Sometimes the page stays blank for a long time and eventually times out.
• When sending a message, the content may remain in the input box for a long time while the send button keeps spinning.
• After waiting for a while, the conversation may suddenly show multiple duplicated copies of the same message. This may be caused by a retry mechanism resending the same content.
• The connection disconnects from time to time, and reconnecting can take a very long time.
• If I have queued multiple instructions and the connection drops, those queued instructions may be lost after reconnecting or reopening the session.
• In some mobile network conditions, especially when multiple bad factors are combined, Codex remote access may fail to connect to the SSH host at all. However, if I connect to the same host directly from a terminal, the connection is still usable, although with noticeable lag and latency.

This issue becomes obvious when connecting to overseas servers where latency reaches a few hundred milliseconds. It also happens when connecting to machines with low outbound bandwidth, such as around 3 Mbps. It is especially common on unstable mobile networks with latency fluctuation and packet loss, such as in cars, on trains, or using in-flight Wi-Fi.

What steps can reproduce the bug?

1. Use Codex remote access (either via phone or desktop app) to connect to an SSH host under weak network conditions.
2. Use a connection with one or more of the following characteristics:
3. High latency, for example several hundred milliseconds.
4. Packet loss.
5. Low bandwidth, for example around 3 Mbps outbound bandwidth.
6. Unstable mobile network conditions, such as cellular networks while traveling, train Wi-Fi, car hotspots, or in-flight Wi-Fi.
7. Open an existing session, especially a long session with a lot of history.
8. Try sending messages, steering instructions, or a sequence of queued commands.
9. Observe session loading, message sending, reconnect behavior, and whether queued messages survive disconnections.

What is the expected behavior?

Remote access should be more resilient and usable under weak network conditions.

Some expected improvements:

• Sessions should support lazy loading. The client should prioritize loading only the most recent session messages first.
• Content that is already completed, collapsed, or not currently visible should not be loaded immediately.
• The client should avoid fetching very long or overly complete session histories all at once.
• Large session data should be split into smaller chunks, so that a single large payload is less likely to fail during transfer.
• Chunked loading should support resuming or continuing from partial progress where possible.
• The retry mechanism for sending messages should be validated and synchronized with the remote side to avoid duplicated messages.
• Local retry behavior should not cause the remote session to receive the same message multiple times.
• Queued messages and steering messages should be cached or persisted remotely, so they can be synchronized across devices and not be lost because of local network issues or reconnects.

Additional information

I frequently control multiple machines around the world through Codex remote access, including machines in the US West, US East, Europe, China, Singapore, Japan, and Australia.

One of my machines in Japan has only about 3 Mbps of outbound bandwidth. I can usually connect to it through Codex remote access only when my own network is very stable. If my local network becomes even slightly worse, Codex may keep reconnecting or fail to connect entirely.

I also travel frequently, and the experience is especially poor on mobile networks. On phones, under unstable network conditions, Codex remote access is often much less usable than a direct terminal SSH connection.