Superapp Architecture: ChatGPT Should Be the Non-Blocking Master Process, Not a Peer Tab

Fair challenge. Let me give concrete examples, then reframe the actual problem.

Process isolation → Agent sandboxing. Codex already runs each task in its own cloud sandbox. This is containerization — the same namespace primitives OS engineers have used for a decade.

Concurrent write protection → Git worktrees. Codex supports up to 6 subagents running in parallel on the same repo, each in an isolated worktree. No merge conflicts. This is copy-on-write with version control — a solved OS problem.

Process scheduler → Orchestrator pattern. Codex has explorer (read-only), worker (read-write), and default roles. A central coordinator dispatches to specialized agents. This is role-based preemptive scheduling.

Filesystem permissions → Tool access controls. Agent A can execute code, Agent B can only search. Capability-based security, straight from OS design.

So @evopyramidai’s concern about “mutable semantic space” is actually already addressed at the file system level — worktree isolation prevents agents from corrupting each other’s work.

But here’s what this reveals: the multi-agent problem is solved. The blocking problem is not.

The correct architecture is three layers:

1. Non-blocking conversation layer (ChatGPT) — the user’s persistent thinking space, never interrupted

2. Blocking task orchestrator (Codex) — manages multiple agents, reviews diffs. Blocking internally is fine — because it runs as a background subprocess, not as the user’s primary interface

3. Multi-sub-agent execution layer (Codex subagents) — already exists, already works, worktree isolation, parallel execution, role separation

Layers 2 and 3 exist today. The missing piece is the connection between layer 1 and layer 2. Right now, to manage your Codex agents, you have to leave the conversation. That’s the blocking point my original post is about — not agent concurrency (which is solved), but cognitive continuity (which isn’t).