Ideas from a remote Codex helper prototype: faster long-session history, durable queue, and MCP process reuse

[Deniskoyyy]

Hi Codex team,

First of all, thank you for the work on Codex. I use it heavily every day, and it has become one of my main development tools.

Recently I built a personal web interface for working remotely with Codex running on my home PC from other devices, such as a laptop or phone. A few days later, OpenAI shipped a very similar remote-work direction, which was exciting to see.

While building and using my prototype, I ran into a few practical issues with the native Codex app and experimented with possible fixes/workarounds.

1. Large session history files can make the app freeze

For long-running conversations, Codex rollout/history JSONL files can grow to hundreds of MB. I have several sessions that are 500 MB or larger. When working with those conversations, the Codex app can freeze for a noticeable amount of time, especially when sending a new prompt.

I think this could be improved either by changing how Codex stores session history, or, if the current JSONL format needs to stay for compatibility/legacy/architecture reasons, by reading the existing files more efficiently.

In my prototype I tested the second approach:

• session summaries and recent user/assistant messages are indexed into local SQLite;
• the session list reads from SQLite instead of parsing large rollout files on the hot path;
• active sessions use bounded head/tail reads;
• heavy technical records such as tool output, command output, and event records are loaded lazily only when opened;
• original Codex files are not modified, so CLI/app compatibility is preserved.

This made the remote UI stay responsive even with very large session files.

2. Durable queued and delayed messages

As far as I understand, the Codex app already has a queue, but in my implementation queued messages are stored in SQLite. That means they are not lost if the app/helper is closed or restarted.

When the current task finishes, saved messages are sent automatically. I also implemented time-based delayed tasks using the same queue storage/processing model.

3. Duplicate MCP server processes

One issue I noticed but have not solved yet is MCP server duplication. It looks like Codex starts separate MCP server instances for different conversations, even when they are the same servers with the same configuration.

On my home PC, I recently had 14 instances each of four MCP servers, around 56 processes total. I also saw a similar pattern on my MacBook: multiple instances of serena, context7, node_repl, and codex app-server --listen stdio://, started in groups as I worked with different sessions.

This is not necessarily critical by itself, but during long-running work it creates extra memory and process overhead. Maybe this could be improved with a shared MCP runtime, reuse of already-running servers across conversations, or more aggressive cleanup of inactive MCP processes.

Other remote-work pieces in the prototype

The prototype also includes:

• live updates via SSE;
• mobile-friendly browsing/continuing of sessions;
• reverse SSH tunnel to the home PC;
• 2FA-protected web access;
• image/attachment support;
• Windows-safe Codex process spawning without shell quoting issues.

I built this primarily for myself, because I use Codex intensively and wanted to remove friction from long working sessions. If any of these ideas overlap with what the Codex team is thinking about, I would be happy to share more implementation details, show a demo, or discuss possible collaboration.

Thanks again for building Codex.

[Deniskoyyy]

Adding screenshots for visual context.

Community thread with additional discussion:
https://community.openai.com/t/feedback-from-a-remote-codex-helper-prototype-long-session-performance-durable-queue-and-mcp-process-reuse/1381062

The screenshots show:

1. Windows desktop UI — remote Codex Helper running against Codex on my home PC.
2. macOS / MacBook access — the same helper used remotely from another device.
3. Phone UI, session list — mobile layout for browsing sessions, queued items, limits, and status.
4. Phone UI, active session — mobile layout for continuing a Codex session.
5. SQLite cache/index view — a large Codex rollout/history file around 588 MB indexed/backfilled, with recent/session messages available from SQLite while keeping the original JSONL unchanged.
6. MCP duplication symptom — Windows tray showing several Serena instances visible at the same time.

[rafaself]

Hi Codex team,

First of all, thank you for the work on Codex. I use it heavily every day, and it has become one of my main development tools.

Recently I built a personal web interface for working remotely with Codex running on my home PC from other devices, such as a laptop or phone. A few days later, OpenAI shipped a very similar remote-work direction, which was exciting to see.

While building and using my prototype, I ran into a few practical issues with the native Codex app and experimented with possible fixes/workarounds.

1. Large session history files can make the app freeze

For long-running conversations, Codex rollout/history JSONL files can grow to hundreds of MB. I have several sessions that are 500 MB or larger. When working with those conversations, the Codex app can freeze for a noticeable amount of time, especially when sending a new prompt.

I think this could be improved either by changing how Codex stores session history, or, if the current JSONL format needs to stay for compatibility/legacy/architecture reasons, by reading the existing files more efficiently.

In my prototype I tested the second approach:

* session summaries and recent user/assistant messages are indexed into local SQLite;

* the session list reads from SQLite instead of parsing large rollout files on the hot path;

* active sessions use bounded head/tail reads;

* heavy technical records such as tool output, command output, and event records are loaded lazily only when opened;

* original Codex files are not modified, so CLI/app compatibility is preserved.

This made the remote UI stay responsive even with very large session files.

2. Durable queued and delayed messages

As far as I understand, the Codex app already has a queue, but in my implementation queued messages are stored in SQLite. That means they are not lost if the app/helper is closed or restarted.

When the current task finishes, saved messages are sent automatically. I also implemented time-based delayed tasks using the same queue storage/processing model.

3. Duplicate MCP server processes

One issue I noticed but have not solved yet is MCP server duplication. It looks like Codex starts separate MCP server instances for different conversations, even when they are the same servers with the same configuration.

On my home PC, I recently had 14 instances each of four MCP servers, around 56 processes total. I also saw a similar pattern on my MacBook: multiple instances of serena, context7, node_repl, and codex app-server --listen stdio://, started in groups as I worked with different sessions.

This is not necessarily critical by itself, but during long-running work it creates extra memory and process overhead. Maybe this could be improved with a shared MCP runtime, reuse of already-running servers across conversations, or more aggressive cleanup of inactive MCP processes.

Other remote-work pieces in the prototype

The prototype also includes:

* live updates via SSE;

* mobile-friendly browsing/continuing of sessions;

* reverse SSH tunnel to the home PC;

* 2FA-protected web access;

* image/attachment support;

* Windows-safe Codex process spawning without shell quoting issues.

I built this primarily for myself, because I use Codex intensively and wanted to remove friction from long working sessions. If any of these ideas overlap with what the Codex team is thinking about, I would be happy to share more implementation details, show a demo, or discuss possible collaboration.

Thanks again for building Codex.

1

I think you should try managing better your threads and contexts, I think reaching 500 MB is a lot. How is your workflow? Also I would try to use lazy loading technique to not load the entire file at one time in the chat app.

2

I think codex doesn't have natively a prompt queue feature in the codex app server. It is usually managed in the client side. Maybe using sqlite is a good approach to persist. But usually, if your app close/restart the connection with the codex app server will be closed as well and thread may be interrupted, as it happens if you close a running thread in the IDE Extension or CLI for example. And if you go back, depending on how you configured the trigger, your queued prompt can be sent automatically after the last interrupted turn.

So the queue feature usually is your customized approach.

[Deniskoyyy]

Thanks for the comment.

On the 500 MB sessions / context management point: I understand the idea, but ideally I do not think users should have to reshape their workflow around the storage/reading limitations of the app. A long-running recurring task in one conversation is also a valid workflow.

For example, I may keep several persistent conversations for the same recurring development tasks and return to them over time. In that workflow, I do not necessarily want to create new chats just because the old one became too large for the UI. I think the app should stay responsive in that case too, especially when most of the heavy history is not needed for the current UI action.

And yes, lazy/indexed loading is exactly what I implemented in the prototype. The UI does not read the full large JSONL file in the hot path. Session lists, metadata, and recent messages are served from SQLite; active sessions read only a bounded window when needed; heavy records such as tool output, command output, and event records are loaded lazily only when the user opens them in the UI. The original Codex files remain unchanged.

On the queue point: agreed, this is more of a helper/client-side layer on top of Codex, not necessarily something the app-server itself has to own. The main idea was that pending prompts should not be lost if the helper UI is closed or restarted. SQLite simply provides durable storage and also gives a foundation for delayed/scheduled prompts.