{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibihtaao2zklas35rfoxpshkttvktwzvxmv65wjxqhp4g73oltxna",
    "uri": "at://did:plc:lk3jfj3zq4k4wxnk474axylu/app.bsky.feed.post/3mlxs5duuito2"
  },
  "path": "/t/feedback-from-a-remote-codex-helper-prototype-long-session-performance-durable-queue-and-mcp-process-reuse/1381062#post_1",
  "publishedAt": "2026-05-16T10:15:06.000Z",
  "site": "https://community.openai.com",
  "tags": [
    "GitHub",
    "Ideas from a remote Codex helper prototype: faster long-session history,...",
    "Codex app can freeze with very large rollout/history JSONL files · Issue #22991 · openai/codex · GitHub",
    "Codex app appears to start duplicate MCP server processes across conversations · Issue #22992 · openai/codex · GitHub"
  ],
  "textContent": "Hi everyone,\n\nI wanted to share some practical Codex feedback and a small prototype direction I have been working on.\n\nI 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.\n\nWhile building and using my prototype, I ran into a few issues that may be useful for the Codex team and other heavy users.\n\n### 1. Very large session history files\n\nLong-running Codex conversations can produce rollout/history JSONL files that grow to hundreds of MB. I have several sessions around 500 MB or larger.\n\nWith those sessions, the native Codex app can freeze for a noticeable amount of time, especially when sending a new prompt.\n\nIn 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.\n\nThis keeps the UI responsive without modifying Codex’s original JSONL files.\n\n### 2. Durable queued and delayed messages\n\nThe 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.\n\nI also implemented time-based delayed tasks using the same queue storage and processing model.\n\n### 3. Duplicate MCP server processes\n\nI also noticed that Codex may start duplicate MCP server instances across conversations, even when the MCP server command/configuration is the same.\n\nOn 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.\n\nMaybe this could be improved with a shared MCP runtime, reference-counted server lifecycle, or more aggressive cleanup of inactive MCP processes.\n\n### Links\n\nI posted the broader GitHub Discussion here:\n\nGitHub\n\n### Ideas from a remote Codex helper prototype: faster long-session history,...\n\nHi 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 r...\n\nAnd two focused GitHub issues:\n\n  * Large session history performance: Codex app can freeze with very large rollout/history JSONL files · Issue #22991 · openai/codex · GitHub\n  * Duplicate MCP server processes: Codex app appears to start duplicate MCP server processes across conversations · Issue #22992 · openai/codex · GitHub\n\n\n\nI would be happy to share more implementation details or show a demo if this overlaps with anything the Codex team is thinking about.\n\nThanks again to everyone working on Codex. It has become a core part of my daily development workflow.",
  "title": "Feedback from a remote Codex helper prototype: long-session performance, durable queue, and MCP process reuse"
}