DEV Community: Arga Fairuz

I Built Checkpoints for AI Agents So You Don't Ruin Your Repo

Arga Fairuz — Mon, 20 Jul 2026 08:29:40 +0000

There's a specific moment every vibe coder eventually has.

You give the agent a broad instruction, something like "refactor the data layer to use the new API client," and it goes further than you expected.

It touches twelve files. Some of the changes are exactly what you wanted. A few are questionable. And at least one file that had nothing to do with the task got modified in a way you don't fully understand yet.

Your first instinct is git. You open the diff. It's a wall of changes across files you weren't watching closely, mixed in with good parts from three prompts ago you don't want to lose.

Reverting the whole commit throws out work you actually want. Cherry-picking individual hunks by hand is slow and error-prone.

You're doing surgery on your own repo at 11pm hoping you don't make it worse.

This is the actual risk of giving an AI agent real autonomy: it's fast, and fast things break fast. The tool that makes you 10x more productive is also the tool most capable of quietly wrecking a working codebase in a single aggressive prompt.

Why plain git isn't built for this

Git is designed around commits you choose to make, at moments you choose.

An AI agent doesn't work in commit-sized units, it works in conversational turns, and a single chat message might span dozens of file edits, several of which you'd want to keep and several you wouldn't.

Bolting your safety net onto the same history you use for actual project commits also means every experimental AI detour risks polluting your real git log.

Worse, it tempts you into skipping careful commits altogether because "the AI will just fix it in the next message."

You need a rollback mechanism built around how agents actually operate, not around how humans commit.

The checkpoint model Clopen runs on

Clopen automatically saves a checkpoint after every chat turn in a session, without you doing anything to trigger it.

Every message that results in file changes gets its own snapshot: full project state, not a diff you have to interpret.

When something breaks, you don't dig through a diff trying to reconstruct what things looked like before.

You open the checkpoint list, find the point right before things went sideways, and restore. Every file goes back to exactly that state, in seconds.

Crucially, this checkpoint history is completely separate from your actual .git history. Your real commit log stays exactly as clean as you left it, because Clopen's checkpoints live in their own tracked layer, isolated from the repository you'll eventually push.

It's not just undo. It's branching

Here's the part that goes beyond a simple rollback button.

Say you're at Checkpoint B, and the next attempt (call it C) breaks something. You restore to B and try a different approach instead, call it B2.

Clopen doesn't discard the C path when you do this, it creates a new branch from B. You now have two histories: A → B → C (broken) and A → B → B2 (working).

If you're curious enough to go fix the original approach instead of abandoning it, you can switch back to the C branch and keep going from there.

Nothing is ever silently deleted just because you tried something else. Every path stays intact and restorable.

Comparing two different implementations of the same feature becomes a matter of switching branches, not maintaining two separate working directories or stashing constantly.

Why this changes how aggressively you prompt

Once restoring to any previous point is a guaranteed, precise, few-second operation, your behavior with the agent changes.

You stop giving small, defensive instructions designed to limit blast radius. You stop reviewing every single file change before letting the agent continue to the next step.

You start handing it the big, ambiguous refactor, because the worst case scenario is a checkpoint restore away, not a manual git archaeology session.

That shift, being willing to let the agent run further before checking in, is where a meaningful chunk of the speed advantage in AI coding actually comes from. Caution has a cost, and checkpoints are what let you stop paying it constantly.

Nothing to configure, nothing to remember

Checkpoints in Clopen aren't an opt-in feature you have to enable and maintain.

They happen automatically as part of every session, which means the safety net is there from your very first prompt, not something you set up after the first time an agent breaks something.

Give the agent the harder task

bun add -g @myrialabs/clopen

Install it, open a real project, and let the agent attempt something bigger than you normally would. If it goes wrong, restore and try again.

Check out the GitHub repository and the landing page to see the checkpoint model in more detail.

Managing Multiple Claude Code and Codex Accounts & Engines Instantly

Arga Fairuz — Fri, 17 Jul 2026 12:25:25 +0000

If you take on client work with Claude Code and Codex, you already know the specific annoyance this article is about.

Client A's account is authenticated in your terminal. You're mid-session, everything's flowing.

Then Client B pings you with something urgent, and now you have to log out of Client A, run through the login flow again for Client B, wait for the browser auth to confirm, and only then get back to actually fixing the thing.

At one point I was running three separate Claude Code accounts for three different clients, plus two Codex accounts, one for a contract and one I kept for testing side projects. Five accounts, one terminal, constant logins.

Do that four or five times a day across a handful of clients and it stops being a minor inconvenience.

It becomes a tax on every context switch, on top of the mental tax of remembering what you were doing before you got interrupted.

The account problem is annoying. The engine problem is separate and just as real

There's a second, less talked about version of this friction. Claude Code and Codex aren't the only serious options anymore.

Tools like OpenCode, Copilot, and Qwen Code all have real strengths depending on the task, the model underneath, or just what you're in the mood to experiment with.

But trying a different engine mid-project usually means a separate install, separate configuration, and often a completely different terminal workflow to learn on the spot.

So most people just don't bother, and stick with whatever they set up first, even when a different engine would genuinely be a better fit.

How Clopen handles multi-account without the logout dance

In Clopen, you add your accounts once, in the UI, and from there switching is a selection in project settings rather than a terminal command.

Each project can be pinned to a specific account, so opening Client A's project just opens it with Client A's credentials already active, and Client B's project does the same with theirs.

You're not checking which account is logged in before you start working. You just open the project.

This matters more than it sounds like on paper. The logout-login cycle isn't just slow, it's a full context reset.

You leave your terminal, deal with an unrelated authentication flow, and come back having to reload the mental state you were in.

Making the switch a single click removes the reset entirely. You're never "logging in," you're just choosing which project to work in, and the account comes with it.

Real engines, real SDKs, not a router trick

The part worth explaining a bit more technically: Clopen doesn't put a proxy or a unified router in front of these tools to fake compatibility.

It integrates with the official SDKs of each engine directly, Claude Code's own SDK, Codex's own SDK, OpenCode's own SDK, and so on.

That distinction matters because a routing layer tends to lag behind upstream changes, silently breaks when an API shifts, and often can't fully expose engine-specific behavior.

Talking to each engine through its own SDK means you get the actual capabilities of that engine, not a lowest-common-denominator abstraction sitting between you and it.

Practically, this means picking OpenCode for a project because you want to try a different model behind it, or because its output style fits a particular kind of refactor better, is a dropdown choice in that project's settings.

No separate install, no new config file to hand-write, no learning a second CLI's flags from scratch.

You pick the engine, the session starts on it, and you can switch back just as easily next session.

Why this is worth solving properly

None of this is the interesting part of the job. Nobody bills a client for the fifteen minutes spent re-authenticating.

But that time, and more importantly, the mental context it costs, comes directly out of the hours you actually want to spend building.

Multi-account and multi-engine support isn't a headline feature you'd put on a landing page hero image. But it's exactly the kind of friction that determines whether a tool feels professional-grade or feels like a demo.

Get your accounts and engines out of your way

If you're juggling clients, or just want to try a different engine without a fresh setup every time, this is a solved problem in Clopen.

bun add -g @myrialabs/clopen

Add your accounts once, assign them per project, and pick your engine per session. Check out the GitHub repository, the landing page, and if you end up wanting a specific engine we don't support yet, that's exactly the kind of contribution the project could use.

How to Vibe Code Multiple Projects Without the Chaos

Arga Fairuz — Fri, 17 Jul 2026 07:00:12 +0000

You've got three tabs open.

Tab one is the internal admin tool you're rebuilding. Tab two is a client's landing page redesign. Tab three is a side project you promised yourself you'd finish this quarter.

Each one has its own AI agent chugging away, each in its own window, each looking almost identical to the other two at a glance.

You step away to answer a Slack message. Five minutes later you're back, staring at three windows.

You genuinely can't remember which one finished, which one is still thinking, and which one has been sitting idle with an error for ten minutes.

So you click into window one. Nothing new. Window two. Still running. Window three. Oh, there it is, it finished eight minutes ago and you missed it.

This is the tax nobody mentions when they talk about running "multiple agents at once." It sounds efficient in theory.

In practice, it turns you into a person who periodically tours their own desktop checking on things. That's not what parallel AI work is supposed to feel like.

Multiple projects were never the problem. Losing track of them was

Running several AI coding sessions in parallel is genuinely a good workflow.

Agents are slow relative to how fast you can think, so having more than one going at once means you're not sitting idle waiting on a single response.

The problem isn't the parallelism. It's that most setups give you zero visibility across sessions unless you're actively looking at each one.

Every time you jump between separate windows, you also lose your mental thread. Which one were you debugging? What was the last thing you asked it to do?

You end up re-reading context every single time you switch, which quietly eats the exact time you were trying to save by running things in parallel.

One tab, all your projects, status visible at a glance

Clopen's approach is to keep every project you're working on inside a single browser tab, as entries in a project list rather than as separate windows.

When an agent in any project finishes a task, that project gets a badge in the sidebar. You're not required to babysit each one, you glance at the list and see exactly which project needs your attention right now.

Switching projects is a click in that list, not a window swap.

You land on Project B while Project A's terminal, its agent session, and whatever background process it had running keep executing exactly as they were. Nothing pauses because you looked away.

That's a meaningfully different guarantee than "the window is still open somewhere." The mental model becomes "everything is always running," not "everything is running as long as I don't accidentally close the wrong thing."

Why this actually changes how you delegate

Once you trust that a project won't silently stall the moment you stop watching it, you start treating your AI agents more like actual coworkers you can hand something off to.

You give an agent a real task, move to a different project, do real work there, and come back when the badge tells you there's something to review.

That loop is closer to how you'd manage a team than how you manage a stack of browser tabs.

It also solves a smaller but very real annoyance: closing the tab by accident, or your laptop going to sleep, doesn't nuke your sessions.

Reopen Clopen and the project list, chat history, and terminal output are exactly where you left them. There's no ritual of "did I save everything before closing this."

This scales past your laptop, too

Because it's all a web workspace, it's not chained to one machine either.

If you start something at your desk and want to check on it later from a different device, Clopen's built-in Public Tunnel makes the same project list, same sessions, same terminal output one toggle away from being reachable anywhere.

An authentication mode in Settings keeps that access yours alone. That's a separate story for another day, but it's worth knowing the multi-project workflow doesn't stop the moment you close your laptop lid.

Stop touring your own windows

If you're running more than one AI coding session at a time, the fix isn't discipline or a better window manager.

It's a workspace that tells you what's happening instead of making you go check.

bun add -g @myrialabs/clopen

Give it a shot on a real multi-project week, and see what it's like when "which one finished" is something you glance at instead of something you investigate. Check out the GitHub repository and the landing page for more.

Why I Stopped Juggling Five Editor Windows and Built a Single AI Coding Workspace

Arga Fairuz — Thu, 16 Jul 2026 15:24:02 +0000

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.