A few months before I started building Clopen, I was carrying five active projects at once.
Not five projects in one place. Five projects, each living in its own separate window or terminal, none of them aware the others existed.
Project A and Project B each had their own Antigravity window open, side by side on my screen.
Project C and Project D were each running through Claude Code, in two separate terminal tabs I had to keep track of individually.
Project E ran through Codex, in yet another terminal window.
That's five windows and terminals open at the same time, each tied to a different project, each one requiring me to personally remember where I'd left off.
The part that made it worse: switching accounts, constantly
Some of those five projects were personal. Others were client or work projects, billed to a different account entirely.
Every time I moved from a personal project to a work one, or back again, I had to manually log out of one account and log into the other, inside whatever tool that specific project happened to be using.
Antigravity had its own session. Claude Code's CLI had its own auth state. Codex had its own login flow.
None of them shared anything. And this wasn't a once-a-day inconvenience, it happened many times within a single working day, every time I context-switched between a client task and something of my own.
At some point, that became the actual bottleneck. Not the AI. Not the code. The five-window, five-account juggling act around it.
Why five windows cost more than they look like they do
Each window or terminal isn't just a visual space, it's a container for state that lives nowhere else.
Claude Code's terminal for Project C held its own command history, its own sense of what had already been tried, its own half-finished train of thought.
Antigravity's window for Project A held a different set of open files, a different chat thread, a different mental model of what was in progress.
To resume any one of these, I had to physically reopen that exact window or terminal, scroll back, and reconstruct where things stood before I could give the next instruction with any confidence.
That reconstruction step is the expensive part. It's not the few seconds it takes to alt-tab, it's the minute or two of rebuilding context after you land somewhere.
Multiply that by five active windows you're rotating through in a single day, and it stops being a minor friction and starts being the thing quietly eating your afternoon.
Why account switching is worse than it sounds on paper
Most AI coding tools, whether it's an editor extension or a CLI, assume one authenticated session per environment.
That's a reasonable assumption if you only ever work on one project for one client. It falls apart the moment you're moving between a personal account and a work account multiple times a day.
Logging out and back in isn't just clicking two buttons. It's clearing a session token, sometimes re-pasting an API key, sometimes waiting on a browser-based auth redirect, every single time you switch context.
Do that enough times in one day and you start avoiding the switch instead, which means work bleeds into personal time, or personal projects get shoved to the end of the day because reauthenticating feels like too much friction to bother with mid-task.
The fix isn't a better window manager, it's a different unit of work
My first instinct was to just get better at managing the chaos. Tighter tmux setup, better window arrangement, keyboard shortcuts for faster alt-tabbing.
None of that actually helps, because the underlying problem isn't about arranging windows better. It's that every one of these tools treats "a terminal" or "a window" as the unit of work, not "a project."
Account, chat history, checkpoints, none of that metadata travels with a window arrangement. Rearranging windows doesn't make five disconnected sessions into one coherent workspace.
What I actually needed was a tool where the project, not the window, was the first-class object. Something where switching between Project A and Project E didn't mean physically relocating to a different application.
That premise became Clopen: one workspace, where every project keeps its own state, and switching between them is a click, not a window hunt.
How this actually works under the hood
Clopen runs every project as its own session inside a single browser tab, rather than as a separate OS-level process tied to a specific window.
Each project keeps its own file tree, its own chat history with the AI agent, its own terminal output, and its own checkpoint history, independently of whichever project currently has your attention.
Critically, projects keep running in the background when you're not looking at them. An agent working on Project E can keep executing while you're focused on Project A, and when you switch back, its state is exactly where it left off, no reopening a terminal, no scrollback archaeology.
For accounts, the fix is structural rather than procedural. Instead of one global authenticated session per tool, Clopen treats the account as a per-project setting you pin once.
Open the personal project, it's already authenticated as your personal account. Open the client project, it's already authenticated as theirs. There's no logout-login cycle standing between you and the next task, because the switch already happened the moment you clicked into the right project.
The same applies to the engine itself. Clopen talks directly to each engine's official SDK, Claude Code, OpenCode, Codex, Copilot, Qwen Code, rather than routing everything through a single proxy layer that flattens them into one generic interface.
That matters because each of these tools behaves differently at the SDK level, and papering over those differences with a shared abstraction tends to lose exactly the behavior that made you pick that engine for that project in the first place.
One command, instead of five separate setups
bun add -g @myrialabs/clopen
That's the whole install. Open it, and instead of five windows representing five projects, you get one workspace with five entries in a project list.
Click into whichever one needs attention, and the right account, the right engine, and the right session state are already there waiting, exactly as you left them.
What's coming next
This piece is the origin story, the actual reason Clopen exists. The deeper technical breakdowns of each individual feature, multi-account SDK switching, checkpoint branching, the tunnel, the database client, are coming as their own articles later this week.
If the five-window, five-account juggling act sounds familiar, that's exactly the problem this project is built around solving.
Check out the https://github.com/myrialabs/clopen, visit the https://clopen.myrialabs.dev, and if you're currently rotating between more windows than you'd like to admit, this is worth five minutes of your time.
Top comments (0)