In October, I ended my update on Codex and Paseo by saying I would build the tool I needed. That became GateFox, now open source under MIT.
The path there had three stages:
| Approach | What it solved | What I still had to manage |
|---|---|---|
| Two Codex desktop profiles | Separate accounts on one Mac | Two application processes and their state |
| Paseo | Named provider profiles and persistent agent processes | A separate interface and its integration with each agent |
| GateFox | Provider access from the coding clients I already use | Authentication, translation, and safe continuation across those boundaries |
First, separate the accounts
My July setup ran the signed Codex app twice. Each account had its own CODEX_HOME; the second instance also needed separate Electron application data. Otherwise the second launch could return to the first process.
That distinction mattered more than the Dock icons. Credentials, history, and local databases belong to an identity. Sharing rules or skills deliberately is useful. Sharing an authentication file defeats the isolation.
The switcher solved opening and focusing those profiles. It left me responsible for keeping two desktop processes healthy.
Then, make the execution host own the work
Paseo changed that setup. Its daemon owned the agents, and accounts became named provider profiles. My laptop and phone could attach to work running on another machine.
That is the part of the architecture I still value: the machine doing the work should own the process. A client disconnect should not decide whether a task survives.
Daily use also exposed the cost of integrating an agent into another interface. My October post records the compaction, authentication, queue, and conversation-display problems I encountered, and the fixes I contributed. Running the native CLI underneath an application still leaves that application responsible for representing its changing behavior correctly.
I wanted to keep more of the existing client experience and make provider access a separate layer.
GateFox has a narrower job
GateFox runs locally and connects authenticated subscription runtimes, API providers, and local models to supported clients such as Codex, Claude Code, and Claude Desktop.
Coding client: conversation, tools, approvals
|
GateFox: account route, protocol translation, streaming
|
Authenticated runtime, API provider, or local model
A configured model alias identifies a provider and account. The gateway translates the request and streams the answer back. The client executes tools and handles approvals. GateFox does not decide the task, grant permissions, or become a new agent orchestrator.
It also does not combine subscription allowances. Accounts keep their own limits. If a selected account fails, a fixed route must not quietly move the request to another identity.
The difficult part is continuity
Getting a model to answer once is the easy demonstration. Three boundaries determine whether I can keep using it:
- Account identity: an alias must keep its credential binding when configuration reloads. A friendly rename must not silently select a different account.
- Conversation identity: saved chats need a provider identity that future engines can still recognize. GateFox keeps its earlier provider ID readable alongside
gatefox, so renaming the product does not require abandoning old chats. - Executed work: a tool result belongs to a particular call in a particular history. Recovery cannot blindly replay a conversation after commands may already have run. Some failures need an explicit refusal instead of another automatic attempt.
Updates have the same constraint. Compatible handlers can take over new requests while existing requests finish on their original code. Connected processes may retain an older release until they become idle. A successful install alone does not prove that every running component has adopted it.
That is the engineering I want to spend time on: keeping accounts, history, and execution consistent while the client remains usable.
Where it stands
GateFox ships a signed, notarized Apple Silicon app. It starts on one Mac; additional Macs can connect over SSH, and the native relay lets the phone list and continue gateway chats while the Mac does the work.
There is more to do: better Claude app integration, a direct DeepSeek API preset, broader client compatibility, and Windows and Linux packaging. Those are contributor issues, not a promise that every harness already works.
The account switcher, Paseo, and GateFox each clarified a different boundary: identity, process ownership, and provider access. GateFox is the part I am building and using now.