Codex / ChatGPT Desktop features start failing one at a time — Computer Use usually dies
first — while open chats and already-connected MCP servers keep working. The cause is file
descriptor exhaustion in the codex app-server process against macOS's default 256 soft
limit, made worse by a known upstream leak where MCP stdio children are never reaped.
This is a containment guide. Upstream tracking issues are linked at the bottom; none are fixed as of 2026-08-21.
TL;DR — ChatGPT for macOS 26.810.x+ spawns Computer Use helper processes in an
unbounded retry loop and dies at ~600 helpers. It needs two ingredients: an uncapped retry
loop in the app (OpenAI's bug), and a symlinked codex home (mine). Removing either one
stops it. I spent five days on the first and fixed it in twenty minutes once I understood the
second.
Investigation ran 2026-08-14 → 2026-08-20 across two Macs. This is the retrospective: what I believed, what was wrong, and what actually found it.
The trigger is a symlinked codex home. The spawn loop needs both an uncapped retry loop in the app and
~/.codex(orCODEX_HOME) reached through a symlink. See openai/codex#39732, independently replicated here on a known-bad build: symlinked → 73 helpers in 27s; resolved real path → 1 helper, flat for 903s. Same binary, same machine, one variable. >
A short ask — clone bb, figure out how it talks to Claude Code / Codex / etc., put findings in a gist — produced a long, sourced research writeup (that gist).
Afterwards I asked the same agent (running as Patch[^patch] inside The Grid[^grid]) whether anything in its instructions nudged that outcome. This note is that answer, rewritten for people who have never seen this setup.
Research notes from reading get-bb/bb (clone: research/repos/get-bb/bb in The Grid) and the locally installed bb 0.35.1 app.
3e3e1934f22afd38a82ccf770cd423c6c2d1c4a2 (2026-08-06)/Applications/bb.app → host-daemon at …/bb-app/host-daemon/dist/packages/agent-runtime, apps/host-daemon, apps/server
This document maps Mike's specific questions and concerns to what the exploration found, where things actually live in the stack, and what's protocol-required vs. solvable at a higher layer.
Mike's question: Stronger isolation of crypto and security concepts. Make it hard to get wrong. End consumers shouldn't care about nonces, inbox IDs, installations. How close can we get?
Where this stands today:
Over the weekend I ran a structured exploration into whether libxmtp's internals, specifically mls_sync and the groups module, could be made meaningfully more modular without forcing a broad public crate split or breaking downstream consumers. These are the two largest and most complex modules in the codebase, and their size has been making it harder to reason about behavior, isolate bugs, and onboard new contributors.
I used my team of agents (Codex & Claude) to do the heavy lifting: planning milestones, executing the refactors, writing tests, and validating the results. The goal was to answer the modularity question with code, not architecture diagrams. Prove or disprove specific internal boundaries, then make a grounded recommendation. The work followed an incremental milestone plan (M0–M8), where each milestone produced reviewable commits and a retro that informed the next step.
Status: Living draft. Section 1 reflects converged direction from the brainstorm; later sections are placeholders to be filled in as the conversation continues. Do not treat unfilled sections as decided.
Signet today runs as a single daemon: the XMTP node, key vault, policy engine, credential lifecycle, and any agent code that consumes credentials all live in one process. That works for a developer running it on their laptop, but it forecloses two things we want:
PR: #553 (consolidated from earlier stacked PRs #538-#541)
I've been using qmd to index agent instruction files and Obsidian-style notes and noticed chunks landing in weird places. Pulled the thread and it turned into four distinct improvements, shipped as one PR with clean commit-per-change history.
The chunker uses scored "break points" (places where splitting is OK) and "protected regions" (places to never split). Four specific issues:
Comprehensive context for designing the next phase of Trails developer experience. Covers three layers: CLI trailhead primitives, the trails CLI tool, and pattern generators. Written April 5, 2026 after shipping beta.14.
These decisions shape the design across all three layers:
Both agents and curious human developers. An agent operates entirely through flags and JSON. A human who runs trails create without flags gets a guided experience. Neither should feel like a second-class citizen.