I still do not have a stable setup for working across my Codex accounts and subscriptions.
In July, I wrote about running two Codex accounts on macOS. In August, I wrote “Paseo Changed Everything About My Multi-Account Codex Setup”. That was an enthusiastic post, and I meant it. Paseo gave me named account profiles, a persistent daemon, and remote access to agents running on my Mac Studio.
After using it longer, reporting bugs, and contributing fixes, I need to update that recommendation. Both approaches helped, but neither gave me the dependable daily workflow I was looking for. I am still looking for that solution, and I have reached the point where I want to build it myself.
Launching two accounts was the first problem
The original Codex setup needed separate CODEX_HOME directories, separate Electron application data, and a controller to keep account switching and the Dock manageable. Both accounts could keep working, but I was maintaining a workaround around two desktop processes. Sleep, crashes, and application restarts were still things I had to think about.
Paseo improved that arrangement. Each account became a provider profile, and the daemon owned the agents. I could close a client and reconnect from another device. I still like that architecture, along with the local execution, open source, and ability to use several providers from one place.
But selecting a profile is only the beginning of managing multiple subscriptions.
I need to know which account a task uses, what usage remains on that account, and how to continue when it reaches a limit or needs authentication again. Work and personal credentials need to stay separate. Moving work between accounts needs a clear handoff, with the original conversation preserved.
My earlier post already said Paseo did not combine accounts, billing, or usage limits. Each subscription keeps its own allowance. What remained unfinished for me was the experience of using those separate subscriptions together without constantly managing the plumbing.
Using an API key is another option, but it changes the billing model. OpenAI’s authentication documentation distinguishes ChatGPT subscription access from usage-based API access. I want a reliable way to work with the subscriptions I already have.
The bugs became part of the work
Some of the problems were small on their own. Together, they made the experience frustrating:
- Codex work could stop around compaction while the timeline still looked busy. I reported an unfinished goal becoming idle with a stuck “Compacting…” marker. My fix for the stale marker was merged. Continuing unfinished goals was tracked separately upstream.
- Authentication recovery could become a dead end. In a Claude session I reported, the error told me to run
/login, then said that command was unavailable. Signing in externally did not make the existing agent recover. With several providers and accounts involved, the error also left me guessing which credential had failed. - The message queue could take over the interface. Queued messages kept expanding until they pushed the composer off screen. I submitted a bounded, scrollable queue fix, which is still open as I write this.
- Reading a conversation was less reliable than it should have been. Opening a linked file and returning to chat could lose my scroll position. Codex citations and Git annotations could appear as raw control syntax.
These reports describe the versions I was using at the time. I also found the Android app and parts of the UI buggy in daily use. Being able to check work from my phone was one of the reasons I liked Paseo, so that friction mattered.
Eventually I was spending too much time diagnosing the interface and keeping fixes alive.
Contributing did not give me a dependable way forward
I tried to help fix the problems. As of 17 October 2026, I had opened twelve pull requests in Paseo. Two were merged, eight were closed without merging, and two remained open.
One merge was quick: the compaction marker fix landed the same day. The other, marking finished workspaces unread, took almost three weeks. It was closed during a cleanup sweep, then revisited and merged after follow-up. The maintainer acknowledged the mistaken closure, and I appreciate that.
Other contributions included account profiles, usage meters, and conversation handoffs, durable subagent queues and a collapsible agent tree, and recovery work for authentication and stopped agents.
Several received a standard closure message directing me to Discussions, without a detailed review of the proposed change. The authentication recovery PR initially asked for a real-session demonstration, then received a follow-up saying it should remain closed unless the maintainer explicitly followed up.
Some submissions received review comments or requests for evidence. What I often lacked was useful follow-through: whether a change had a path forward, what would make it acceptable, or whether I should stop maintaining it.
The maintainer explained that there were hundreds of PRs and that individual reviews and timelines could not be promised. I understand the capacity problem. For my workflow, though, the pace was too slow and the outcome too uncertain. Keeping branches current, rerunning checks, and waiting for decisions became another job.
Worktrees and native subagents need more care
I praised worktree isolation in the earlier post, and it remains useful. Separate tasks often deserve separate branches and directories.
In daily use, I found the additional workspace setup and coordination heavier than I wanted. Separate agent sessions can also repeat context and use more of a subscription’s allowance. Worktrees themselves do not consume model tokens; the extra agent work around them is where that cost can grow.
I want isolation to fit the task. Sometimes I need a separate worktree. Sometimes I want a native subagent to handle a focused part of the work inside the provider’s existing workflow.
Paseo launches the native Codex and Claude runtimes, but that alone did not make their full capabilities feel native in its interface. I wanted better visibility into parent and child agents, queues, progress, stopping, and recovery. The goal and annotation issues were reminders that an adapter also has to keep up with how a provider behaves.
Cross-provider orchestration is useful. For me, it needs to work well alongside the native subagent features of Codex and Claude Code.
What I want to build
I want one place where I can see my accounts, their subscription usage, and the tasks attached to each one. Authentication failures should name the affected account and offer a recovery path that works. Continuing through another account should preserve the original thread and make the handoff visible.
I also want native subagents to remain visible and controllable, worktrees to be a deliberate choice, and the desktop and Android interfaces to handle ordinary things reliably: reading a conversation, queuing a message, stopping an agent, and reconnecting.
Paseo showed me a lot of what I liked. Using it every day showed me what I still needed. I would happily use a stable existing solution that fits this workflow, but I no longer want to keep waiting for one.
I am going to build the version I need. When it is working well enough for me to rely on, I will share it with the community.