Feedback from a remote Codex helper prototype: long-session performance, durable queue, and MCP process reuse

Codex
, ,
1

Hi everyone,

I wanted to share some practical Codex feedback and a small prototype direction I have been working on.

I use Codex heavily every day. Recently I built a personal web interface that lets me work remotely with Codex running on my home PC from a laptop or phone. Shortly after that, OpenAI shipped a similar remote-work direction, which was exciting to see.

While building and using my prototype, I ran into a few issues that may be useful for the Codex team and other heavy users.

1. Very large session history files

Long-running Codex conversations can produce rollout/history JSONL files that grow to hundreds of MB. I have several sessions around 500 MB or larger.

With those sessions, the native Codex app can freeze for a noticeable amount of time, especially when sending a new prompt.

In my prototype, I worked around this by indexing session summaries and recent user/assistant messages into local SQLite. The UI reads summaries and recent messages from SQLite, reads only bounded head/tail windows for active sessions, and lazy-loads heavy technical records such as command output, tool output, and event records only when the user opens them.

This keeps the UI responsive without modifying Codex’s original JSONL files.

2. Durable queued and delayed messages

The Codex app already has a queue, but I made the queue durable by storing pending messages in SQLite. If the app/helper is closed or restarted, queued messages are not lost. When the current task finishes, saved messages are sent automatically.

I also implemented time-based delayed tasks using the same queue storage and processing model.

3. Duplicate MCP server processes

I also noticed that Codex may start duplicate MCP server instances across conversations, even when the MCP server command/configuration is the same.

On my home PC, I recently saw 14 instances each of four MCP servers, about 56 processes total. I also saw a similar pattern on my MacBook with repeated serena, context7, node_repl, and codex app-server --listen stdio:// processes.

Maybe this could be improved with a shared MCP runtime, reference-counted server lifecycle, or more aggressive cleanup of inactive MCP processes.

Links

I posted the broader GitHub Discussion here:

And two focused GitHub issues:

I would be happy to share more implementation details or show a demo if this overlaps with anything the Codex team is thinking about.

Thanks again to everyone working on Codex. It has become a core part of my daily development workflow.

2

Welcome to the forum!

This is an excellent first post!

I especially appreciated the link to the related discussion and your note about the relevant Codex issues.

3

This looks good.

Definitely worth the demo vid to reach a larger audience.

:clinking_beer_mugs:

4

Thanks for sharing this, @Deniskoyyy

The SQLite indexing approach sounds especially interesting. I wonder what's the architecture behind it? In particular, how are you ingesting the JSONL incrementally, what tables/indexes are you using?

- Avinash

5

Looks like new users can only attach one embedded media item per post, so I’ll add the screenshots one by one. Fair enough :slightly_smiling_face:

Windows desktop UI

This is the main remote Codex Helper interface running against Codex on my home PC. It shows the session list, usage/limit indicators, active conversation view, collapsible action groups, and queued items.

CH1
CH11916×991 356 KB

6

macOS / MacBook access

The same helper accessed from my MacBook. The idea is that Codex continues running on the home PC, while the UI can be used remotely from another device.

Снимок экрана 2026-05-16 в 19.21.15
Снимок экрана 2026-05-16 в 19.21.151920×1045 331 KB

7

Phone UI, session list

Mobile layout for browsing Codex sessions, seeing queued/pending items, checking status, and selecting a session while away from the main machine.

IMG_1116
IMG_11161290×2796 460 KB

8

Phone UI, active session

Mobile layout for continuing a Codex session and reading the conversation/actions from a phone.

IMG_1117
IMG_11171290×2796 361 KB

9

SQLite cache/index view

This shows the local cache/index layer for Codex session files. In this example, one rollout/history JSONL file is around 588 MB and is fully indexed/backfilled, with recent/session messages available from SQLite while the original Codex file remains unchanged.

CH2
CH21266×887 185 KB

10

MCP duplication symptom

Small Windows tray screenshot related to the duplicate MCP/server process issue. Several Serena instances are visible at the same time, matching the process accumulation pattern I described in the GitHub issue.

CH3
CH3230×263 16.4 KB

11

Thanks, EricGT!

I appreciate the welcome. I tried to keep the post constructive and split the details into a broader GitHub discussion plus focused GitHub issues, so the product idea and the concrete technical problems can be tracked separately.

I also added the screenshots above as separate replies because new users can only embed one media item per post. They show the helper across Windows, macOS, and phone, plus the SQLite cache/index view and the MCP duplication symptom.

12

Thanks!

I added screenshots above as visual context: Windows desktop, macOS/MacBook access, phone UI, the SQLite cache/index view, and the MCP duplication symptom.

That should make the prototype and the concrete issues easier to understand without turning the thread into a long separate walkthrough.

13

Thanks, Avinash.

At a high level, I keep Codex’s original JSONL/session files unchanged and add a local SQLite read/index layer next to them.

The ingestion flow is incremental:

  1. The helper discovers Codex session/rollout files and stores per-file cache state.
  2. For each file, it tracks a watermark/offset and file metadata, so it can continue from the last indexed position instead of reparsing the whole JSONL file.
  3. New JSONL records are parsed and normalized into lightweight session summary/recent-message rows.
  4. Heavy technical records such as command output, tool output, and event records are not eagerly expanded into the normal session list path. They are loaded lazily only when the user opens the corresponding action/output in the UI.
  5. For active sessions, the UI can still read a bounded head/tail window from the original file when needed, but the hot path for listing sessions and recent messages is served from SQLite.

The main tables are roughly:

  • session_summaries: one row per session/file with metadata used for the session list;
  • session_recent_messages: recent user/assistant messages used for fast previews and session resume UI;
  • session_file_cache_state: file path, size/watermark, and indexing/backfill state;
  • queued_commands: durable pending commands/messages;
  • runtime_sessions, runtime_rate_limits, runtime_settings: runtime/helper state.

The important part is that the original Codex JSONL files remain the source of truth and are not modified. SQLite is only an index/cache layer optimized for UI reads.

I added a cache/index screenshot above as context. It shows a large session file around 588 MB fully indexed/backfilled, with recent/session messages available from SQLite.

14

What I want to know is how as new user you were able to post more then two replies in a row?

That is not a question to you but to the admins of this site. I as TL4 can not even post more than 2 replies in a row.

15

other people’s threads = true
your own = false

i think

16

Apparently bugs find me on their own :slightly_smiling_face:

I first tried to edit the original post and attach the screenshots there, but then discovered that as a new user I could not embed multiple media items. I also hit the link limit while editing, so I ended up posting the screenshots one by one as replies.

Not sure why it allowed more than two replies in a row here. Maybe because they were mostly media/context posts, or maybe Discourse trust-level rules are a bit different in this category.

17

FYI

If there is something you want to do, like create a reply with more than the limit of links, put sevearl replies in a row into one, etc. just flag your post, select other, and then explain what you would like done so the moderators can address your need. If they can do it most likely they will.

18

Thank you for the amazing work you put in! @Deniskoyy

- Avinash

19

Thanks, good to know!

I’m genuinely very new to this forum, so I’m still learning how the posting limits and moderation tools work.

Appreciate the tip :heart:

20

Thank you, Avinash. I really appreciate it.

Since I use Codex and ChatGPT very heavily, I keep running into edge cases and workflow issues like these, and I enjoy turning them into clear repros or prototype fixes.

If there is an appropriate channel for deeper Codex QA/testing, developer feedback, or potential collaboration with the team, I would be grateful if you could point me in the right direction.