DEV Community: Guo Mengyue

Keeping AI coding work resumable: projects, sessions and handoffs in Termexo

Guo Mengyue — Sun, 13 Sep 2026 12:38:29 +0000

An AI coding task can stop for several reasons: a test fails, the agent needs approval, or you have to switch projects. Starting another terminal is easy. Remembering what each terminal was doing is the harder part.

I maintain Termexo, an MIT-licensed Windows workbench for organizing AI coding terminals. Its direction is to keep projects, agents, model settings and session context together, with browser access to the same running desktop when needed. This post describes a workflow to try, including the parts that still need a person.

Give every terminal a project and a job

Start with one repository and two tasks: implementing a change and checking it. Write an acceptance condition before starting either task. For a login form, that could be: an invalid credential response shows a useful message, and the corresponding test passes.

Termexo groups project directories, terminal layouts and related settings into workspaces. It supports Claude Code, Codex CLI, OpenCode and Antigravity, presenting their real terminals. The task board helps connect the work to goals and acceptance.

Repository screenshot with demonstration data. A task reaching a completed state still needs review.

When two agents work concurrently, define which files each may change and which task depends on the other. A shared workbench does not automatically resolve conflicting edits. Separate branches or worktrees can help when appropriate; the developer remains responsible for integration.

Treat waiting as something you need to see

A running process is not necessarily making progress. It may be waiting for input or approval. Status indicators and notifications help expose those moments so you can return to the relevant terminal and make the decision.

For a small trial, notice whether you can identify the waiting task without opening every terminal. That is a more useful evaluation than counting how many agents are open.

Leave a handoff that another session can use

Native session search and recovery help reopen supported agent sessions. When changing tools or handing work to another person, use a reviewed handoff with four parts:

Goal: what behavior should change, and how will it be accepted?
Progress: what changed, and where is the code?
Verification: which checks ran, what passed, and what remains unverified?
Next step: one concrete action, including unresolved constraints.

For example: “The login error message is implemented. The unit test passes. Browser behavior has not been checked. Next, verify keyboard submission and add the missing test if it fails.”

Termexo's handoff packages help carry this background. They are not a complete transfer of an agent's private context, and the receiving environment still needs the code, CLI and relevant configuration.

Reach the running desktop from another device

Browser access can be useful when a long task needs a short response while you are away from your desk. Trusted local networks or controlled VPNs can use direct access; cross-network access can use a reachable self-hosted HTTPS relay.

Project interface imagery illustrating access to the desktop from a phone.

The Windows host must stay on, with Termexo running and connected. The terminal processes execute there. Plan for sleep settings, connectivity and access credentials before relying on the remote workflow.

Where this fits today

For an individual developer, the use case is maintaining several projects without repeatedly reconstructing their state. Within an engineering team, the current fit is each member organizing their own workbench and producing clearer handoffs.

Shared workspaces, fine-grained permissions, centralized audit and fuller automatic orchestration remain longer-term plans. Local-first describes where the workbench and its state run; sending code to an external model still depends on the agent, endpoint and model configuration.

Try a complete cycle: define a task, implement it, check it, resume a session and review a handoff. Add remote access only if it solves a real interruption in your day.

Source and releases: gemron/Termexo. Setup and remote access: project guide. Agent CLIs, accounts and model services require their own setup.

Written by the project maintainer with AI assistance. Images come from the project and include demonstration content.

I Have Five Claude Accounts and No Idea Which One This Terminal Is Spending

Guo Mengyue — Thu, 03 Sep 2026 15:25:37 +0000

Disclosure: I maintain Termexo, the project this post is about. It is free and MIT licensed — there is nothing to buy. This write-up was drafted with AI assistance from my own notes and the project's source, and I have checked every technical claim in it against the code that ships in V0.7.0.

If you run more than one Claude Code or Codex terminal, you have probably hit this moment:

Your usage is nearly gone, so you open a new terminal on a different account and type claude. It starts. But which account is it actually signed in as? Nothing in the interface tells you. You are left reasoning from "did I remember to set that environment variable?" — and when you guess wrong, you quietly burn the wrong subscription.

Termexo V0.7 is mostly about that: making the account a visible, changeable property of a terminal instead of invisible state hidden in an environment variable.

I maintain Termexo. It is a Windows-only, local-first workspace for coding agents, MIT licensed. It does not replace Claude Code, Codex, or OpenCode and does not re-skin their chat interfaces — all three keep running in real PTY terminals. Termexo owns the layer above: workspaces, layout, state, sessions, tasks, and accounts.

The account lives in a directory, not in a key

The constraint that shapes everything else: for Claude Code and Codex, identity is not a swappable token. It is an entire configuration directory.

Claude Code reads CLAUDE_CONFIG_DIR
Codex reads CODEX_HOME

Credentials, identity (userID, oauthAccount, machineID), session transcripts, and caches all live under that directory. Whichever directory you point at, that is who the CLI is.

Termexo gives every managed account its own directory. "Switching accounts" therefore means changing an environment variable — and a running process cannot be told to change its own environment.

That single fact is what makes this a lifecycle problem.

Two-phase launch, so the frontend never touches secrets

Termexo already launched agents in two phases, so the switch reuses it:

1. prepare_claude_launch(terminalId, accountProfileId, profileId, …)
   → resolve the account, model, and network profiles
   → read API keys from Windows Credential Manager
   → write this terminal's hook configuration
   → stash the full environment map in LaunchEnvironmentStore, keyed by terminalId
   → return only an AgentLaunchSpec (a command string and an executable path)

2. create_terminal(terminalId, …)
   → PtyManager::start takes (not reads) that environment out of the store
   → injects it into the PTY

The frontend never receives a key and never builds a command line. It generates terminalId with crypto.randomUUID() before step 1 and reuses it.

So switching an account becomes:

// 1. Build the new launch command first.
const launch = await prepareLaunch({
  terminalId: original.id,
  accountProfileId,          // ← the only thing that changes
  profileId: original.profileId,
  mcpProfileId: original.mcpProfileId,
  autoConfirm: original.autoConfirm,
});

// 2. Only now touch the running PTY.
await terminalGateway.close(original.id);

// 3. Restart on the new command.
state.restartTerminalWithProfile(original.id, launch.command, {
  model: original.model,
  profileId: original.profileId,
  mcpProfileId: original.mcpProfileId,
  accountProfileId,
});

The order matters. If preparation fails — the account directory cannot be created, a credential is gone — the error is thrown before close(), and the running session is untouched. Build the replacement, then dismantle the original; never the other way round.

The restart always starts a new session, and that is honest

The dialog says "new session" in plain words. Not because resuming is hard, but because it is semantically wrong:

A transcript physically lives in the previous account's configuration directory (~/.claude/projects/**/*.jsonl). Under the new account's directory that session id does not exist, and claude --resume <id> simply fails.

So the restart clears nativeSessionId, and the UI says so up front rather than letting you discover it when your first message kills the terminal.

Reconnection has to rebuild the environment

LaunchEnvironmentStore is a take-once, in-memory store. After the app restarts, terminals reconnect — and that environment is long gone. Left alone, the CLI falls back to its default home and silently becomes a different account.

The fix is to let a terminal remember its own identity and rebuild from that record:

pub(crate) fn relaunch_environment(
    database: &WorkspaceDatabase,
    credentials: &CredentialStore,
    agent_type: &str,
    account_profile_id: Option<&str>,
    model_profile_id: Option<&str>,
    workspace_id: Option<&str>,
) -> Result<HashMap<String, String>, String>

create_terminal takes this path whenever the stash is empty, rebuilding the account directory, proxy settings, and provider key. A terminal you switched stays switched across restarts, because the new accountProfileId was written back to its record.

One more thing: signed in, and asked to sign in again

While building this I tracked down an old annoyance: an account that had already completed claude auth login was asked to log in again the first time a terminal opened on it.

Claude Code decides whether to run its first-run wizard from a single flag in the configuration directory — hasCompletedOnboarding — and that wizard always includes a login step, regardless of whether valid credentials are sitting right there. Earlier claude auth login builds never set the flag after a successful sign-in, so every account signed in by one of them met the wizard's login screen every time.

Termexo now writes the flag when the account directory already holds credentials. Writes go through a sibling temp file and a rename, so a CLI reading concurrently never sees half a file; a damaged config is skipped and logged rather than overwritten, because Claude repairs it from its own backups and rewriting would destroy what it repairs from.

An account that has not signed in still gets the wizard — that one needs it.

What else landed in V0.7

The window draws its own chrome. No system title bar: the top bar spans the whole window with the window controls at its right edge, and both side panels start beneath it, the way an editor lays out.
Terminals render on the GPU. Long scrollback scrolls without the DOM renderer's stutter; machines without a usable GPU fall back automatically.
Drag-to-reorder works again for terminal tabs in the desktop build, where the webview's own drag handling had been eating the events.
Configuration copies between accounts — settings, instructions, plugins, and skills. Credentials, identity, and session history never travel, so both accounts stay signed in as themselves.
A finished sign-in is detected on its own, rather than waiting on a login CLI that keeps running after the browser flow has already returned.

Boundaries, kept on purpose

There is no Termexo account and no cloud relay. Workspaces, terminal configuration, the session index, and events live in local SQLite. API keys live in Windows Credential Manager. Native session files stay read-only — Termexo parses them and never rewrites a JSONL to make its own UI tidier.

Local-first does not mean the model requests are offline: Claude Code, Codex, and OpenCode still reach whichever provider you configured, under that provider's own terms and privacy policy. Termexo orchestrates locally; it does not proxy your requests.

Try it

Windows 10/11 x64, WebView2, Node.js 18.18+:

npx termexo@latest

Known limits: Windows only for now, and third-party endpoints for Codex need the provider to be compatible with the Responses API — being OpenAI-compatible is not always enough.

The source and the V0.7.0 release notes are on GitHub, and there is a project site at termexo.com.

I maintain this project, so take the framing above for what it is — the account problem is the one I hit myself. The feedback I want most: when you run several coding agents at once, where does your workflow lose the most context — planning, approval, recovery, or accounts and quota?