ClikCode

The harness that logs in all your favorite AI coding providers — in the terminal and in VS Code. Chats you can resume in any of them, and automatic account switching when you hit a usage limit.

Claude Code for one thing, Codex for another, Copilot because it came with the
editor, something you tried once and kept. Each has its own commands, its own
sign-in, its own idea of where your conversations live. None of them know the
others exist, so picking one up means learning it again and leaving your work
behind in the last one.

ClikCode sits in front of 29 of them, including four newer ACP agents under
experimental support. One sign-in, one list of conversations, one
set of controls, the same keystrokes whichever tool answers. It replaces
nothing — your tools stay yours, the logins you already had keep working — and
what it adds is this:

For the 21 harnesses with an ACP entry point or adapter, ClikCode uses ACP for
ordinary turns. When an agent cannot carry a particular image, model, or
reasoning choice over ACP, ClikCode uses that harness's CLI path where safe.
Any other ACP agent can be added with clikcode acp add, and it then appears
in the same provider list.

For example, clikcode acp add my-agent /path/to/agent -- --stdio registers
an installed ACP executable without changing ClikCode. In VS Code, use
Add ACP Harness… and enter launch arguments as a JSON array, such as
["--stdio", "--config", "two words"]. The agent still needs its own usable
credentials; a completed turn and resume should be checked before relying on
it for work.

Every tool, one way of working. Stop memorizing flags. ClikCode asks each
tool what it supports and offers you that — models, reasoning level, approval
behavior — in the same place every time.

All your accounts, at once. Work and personal, two subscriptions, an API
key kept for spillover. Keep them side by side and move between them in a
keystroke. Signing in still happens inside the tool itself; ClikCode never
sees your password or your key, only which account is which.

One list of conversations. Not one list per tool. Whichever one you were
using when you started a chat, it is in the same list, and you can carry it on
somewhere else. Chats you began in Claude Code or Codex directly, long before
ClikCode was involved, are in that list too.

Run out, and keep going. When an account hits its limit, ClikCode moves to
the next one and the answer keeps arriving. It takes the conversation with it,
so the model continues from what was actually said rather than a summary of
it. Nothing to click. You find out afterwards.

Install

npm install -g clikcode

Update the same way: npm install -g clikcode@latest. Without access to the npm
registry, install the same release from GitHub:
npm install -g https://github.com/Jgracier/ClikCode/releases/latest/download/clikcode.tgz.

For VS Code (and VSCodium, Cursor, Windsurf), the ClikCode extension
(clikcode.clikcode, on the Visual Studio Marketplace and Open VSX) puts the
same chats in a panel beside your code; it runs the ClikCode you installed.

Requires Node.js 22.12 or newer. Nothing to configure. You do not need any
of the coding tools installed first: choose one — to sign in, or as the tool for
a conversation — and ClikCode installs it for you, with the vendor's own npm
package or installer.

Deep Agents Code, Devin CLI, Junie CLI and MiniMax Code are experimental ACP
integrations. Their official install and launch commands are wired. Devin,
Junie and MiniMax Code installed and answered ACP initialization on Linux;
authenticated turns remain unverified without usable vendor accounts. When an
agent offers one browser sign-in method over ACP, an interactive ClikCode turn
uses it; terminal sign-in methods still run through the vendor's CLI. See the
per-harness verification record.

Google ended Gemini CLI access for individual accounts.
Gemini Code Assist enterprise licenses and API key access remain supported by
the vendor; ClikCode cannot restore individual-account access.

Your first five minutes

Start by seeing what you can sign in to, then sign in to something:

clikcode accounts providers          # every supported tool, and how each signs in
clikcode accounts login claude       # installs the CLI first if you need it
clikcode                             # start talking

That second command runs the vendor's own sign-in — the same browser window
you would have seen running claude yourself. ClikCode watches it happen and
notes that the account exists. It does not read what came back.

Add more whenever you like, and name them so you can tell them apart:

clikcode accounts login claude --label work
clikcode accounts login codex --label personal
clikcode accounts list               # what you have, and what is left on each

Now type clikcode and you are in a session. Press / for a searchable list
of everything you can do from here. That is the whole setup.

Three things to know

Everything in ClikCode is one of three nouns, and they stack in this order.

A tool is Claude Code, Codex, Gemini, Copilot — the thing that actually
does the work. clikcode doctor tells you which ones are on this machine, what
version, and what each can do.

An account is one sign-in to one tool. Most people end up with several.
Accounts are kept apart from one another, and apart from the login you already
had before ClikCode existed — that one keeps working exactly as it did.

A conversation belongs to you, not to a tool. It has a name, a history and
a working directory, and it survives changing your mind about which tool or
which account should answer it. Running clikcode with no arguments picks up
the last one you were in.

Driving it

Two keys do almost everything.

Right Arrow opens, and Right Arrow selects. On an empty line it opens the
command list. On a highlighted row it opens that row — a tool, an account, a
conversation. You can go a long way without typing anything.

Left Arrow goes back out of any menu or picker, and never confirms. That
one rule is why you can explore a menu without worrying about setting something
by accident. (In the composer it moves the cursor, as you would expect.)

Enter sends. For a newline that works in every terminal and over every SSH
client, end the line with a backslash and press Enter; Shift+Enter also works
where the terminal supports it.

Scrolling with a mouse or a trackpad works. When you want your terminal's own
selection instead — to copy something out — /select releases the mouse, and
/select again takes it back.

Signing in, and adding more

clikcode accounts login <tool> runs that tool's own sign-in and gives the
result a name. Run it again with a different --label and you have a second
account. Nothing stops you at two.

That is what makes the rest possible — running out only survives if there is
somewhere else to go.

Each account gets its own directory under ~/.clikcode/profiles/, and
ClikCode points the tool at it using that vendor's own supported setting —
CLAUDE_CONFIG_DIR, CODEX_HOME, COPILOT_HOME, GEMINI_CLI_HOME,
QWEN_HOME and so on — for
one child process at a time. Nothing global changes, and the ~/.claude,
~/.codex logins you already had are untouched.

Nine tools work this way today: Claude Code, Codex, GitHub Copilot, Gemini
CLI, Qwen Code, Antigravity, Pi, Hermes and Command Code. The rest hold one
account each — usually an API key — added with clikcode accounts add.

Two of the nine, Antigravity and Command Code, have no such setting, so
ClikCode points HOME elsewhere for that one process instead. On its own that
would also hide your git, npm, GitHub CLI, Docker, GnuPG, Cargo, rustup and ssh-agent
configuration from the agent, so ClikCode points those back at your real home.
Turns still commit, push and install as you.

Switch by hand with /account in a session, or
clikcode sessions set <id> --account <label>.

When an account runs out

ClikCode watches how much each account has left — /usage shows it, and it
sits in the corner of the screen while you work. When the one you are on is
spent, the turn moves to another account of the same tool and the answer keeps
arriving. You are told after the fact, not asked first.

What travels is the point. ClikCode copies the tool's own conversation file
into the next account and resumes it there, so the model continues the real
thread instead of a summary of it. It does not re-read your project, and it
does not forget what it just said.

This is on by default. Turn it off for the current conversation with
/accounts failover never, or for a new one with
clikcode sessions create --account-failover never.

Resume anything, from anywhere

/resume shows two things: your ClikCode conversations, and chats the tools
started on their own — ones you ran in Claude Code or Codex directly, before
ClikCode was involved.

Pick one of the second kind and it becomes one of the first. It gets a row in
your list, and you can carry it on, fork it, rename it or hand it to another
tool.

Claude Code, Codex and OpenCode hand over their full history when adopted, so
you can scroll back through it. For the others the thread is real and the tool
remembers all of it, but ClikCode's own view starts at your next message.

Moving a conversation to another tool

Changing accounts keeps you on the same tool. Changing the tool is one
command: /provider to pick from a list, or its name directly — /claude,
/codex, /gemini — with your next message on the same line.

/codex have another look at the migration

The conversation keeps its name, its history and its place in your list. No
vendor can read another vendor's memory, so the new tool is sent the
conversation so far as context. On a long thread that costs tokens and a few
seconds. Nothing else changes.

One MCP server, whichever tool you choose

Tools that support MCP each want it configured their own way. Add a server
once. ClikCode's own agent uses it immediately. Another harness gets it the
first time you choose that provider, and only if that name is not already
there:

clikcode mcp targets                        # how each harness would receive it
clikcode mcp add postgres -- npx -y pg-mcp  # record it; install on choose

ClikCode does not host or proxy these servers. Each tool talks to them
directly, exactly as it would if you had configured it by hand. Skills follow
the same rule. Hooks are never copied: Claude Code and Grok already run
Claude's hook files themselves, and every other harness uses its own hook
format, so ClikCode leaves those alone.

Everyday commands

Everything above is reachable from the command line too, for scripting or for
when you would rather type than pick.

Output is JSON when it is not going to a terminal, so ClikCode scripts
cleanly -- one record per line, so a command that reports twice is still
parseable -- and readable text when it is. --json or --human forces one,
and --debug adds the stack and HTTP detail when something fails.

Inside a session

Most of the time you will not type any of those. You will be in a session,
where everything is a slash away.

Pressing / opens a searchable list. Six are pinned at the top, in the order
people reach for them: pick a tool, pick an account on it, resume a
conversation, change the model, start over, change what needs your approval.

/help lists every command grouped by topic instead of by frequency, since a
reference reads better that way. The remaining ~35 commands, grouped as
/help groups them:

Conversation

Workspace

Provider

Settings

Sessions

Info

A command that doesn't apply right now — no provider chosen yet, or a
Gateway-managed setting on the ClikDeploy Gateway route — stays listed with a reason
(unavailable · …) instead of disappearing, so the palette always explains
itself.

Two shortcuts are not in the list but work anywhere. Typing a tool's name —
/claude, /codex — hands the conversation to it, with your next message on
the same line if you want. And // sends whatever follows straight to the
tool, unchanged, for the occasions when you want its own syntax rather than
ClikCode's.

Some tools bring commands of their own (/mcp, /plugins, …), and a few
announce more mid-conversation. Those work when typed and appear in /help,
but stay out of the pinned list so they don't read as ClikCode's. So do your
own: drop a *.md prompt template in .clikcode/commands/ for this project,
or ~/.clikcode/commands/ for all of them, and it becomes a slash command
named after the file.

Running without a vendor tool

Everything above assumes the tools are on your machine. When they are not,
sign in to ClikDeploy Gateway instead: it supplies the model, and ClikCode runs
the coding agent itself — same conversations, same commands, no vendor CLI.

Nothing is routed through it until you sign in with clikcode gateway login.
The gateway is ClikDeploy Gateway, and it is listed with your other providers.

What ClikCode keeps, and where

Everything it owns is under ~/.clikcode, readable only by you (directories
0700, files 0600):

• index.json — accounts (labels and credential references), the session
  index, usage records and the installation id
• secrets.json — the local control API token and this device's key
• sessions/ — session records and history
• profiles/<harness>/<account-id>/ — per-account vendor configuration roots
• runtime.json, runtime.lock — present only while the control API is running
• crash.log — uncaught errors

Set CLIKCODE_HOME to relocate the state directory (tests, portable installs).
crash.log and a gateway credential, if you sign in, always live outside it:
~/.clikcode/crash.log, ~/.config/clikcode/auth.json (or under
$XDG_CONFIG_HOME) and ~/.clikcode/api-key.

Letting other programs drive it

An editor, a script or another agent can drive ClikCode over a small HTTP API.
clikcode start runs it; clikcode status and clikcode stop inspect and
stop it. It stays off until you start it.

• Binds to 127.0.0.1 only, on an OS-assigned port (or --port); the URL is
  printed and recorded in ~/.clikcode/runtime.json.
• GET /v1/health is unauthenticated. Every other route (/v1/accounts,
  /v1/device, /v1/models, /v1/sessions, /v1/usage, /v1/chat) requires
  Authorization: Bearer <token>, a per-installation token kept in
  secrets.json. Requests whose Host is not loopback are refused.
• Responses never contain credential material.

Tuning and accessibility

Two of these matter even if you set nothing else. CLIKCODE_SCREEN_READER
switches to a plain, append-only view that a screen reader announces once and
in order. CLIKCODE_REDUCED_MOTION holds the spinner still; the answer still
streams at full speed.

Development

If you want to work on ClikCode itself:

pnpm install
pnpm build          # dist/index.js, dist/harness-catalog.cjs, dist/ai-router-runtime.cjs
pnpm build:analyze  # + bundle report: top inputs by bytes, runtime packages
pnpm build:strict   # + fail on a missing or extra runtime dependency
pnpm type-check     # tsc over src/ and over packages/clikrouter
pnpm test           # the ClikCode suite
pnpm test:router    # the router package's suite
pnpm test:all       # both suites
pnpm test:smoke     # build, then --help and doctor against the built binary
pnpm test:pack      # assert tarball contents, npm install -g it into a temp prefix, run it
pnpm test:display   # the terminal UI driven in a real pty: nothing flashes, vanishes or doubles

Three packages, one lockfile:

• src/ — the CLI, one folder per layer: cli/ (argv, output modes, errors),
  commands/ (the verbs), session/ and turn/ (state and the turn loop),
  agent/ (ClikCode's own coding agent: tools, permissions, checkpoints),
  harness/ (driving the vendor CLIs over argv/ACP/app-server),
  gateway/ (the gateway adapter), tui/, daemon/, runtime/.
• packages/clikrouter (@clikcode/router) — provider-agnostic request
  normalization and router selection across dozens of providers, consumed as source
  and bundled into dist/*.cjs.
• packages/vscode — the VS Code extension (clikcode.clikcode). It runs the
  installed ClikCode through clikcode ide-bridge (src/ide/); its own checks are
  pnpm --dir packages/vscode type-check, test, run package and, in a real
  VS Code, test:integration.

dist/index.js inlines the small pure-JS dependencies (chalk, commander, conf,
cross-spawn, marked) so startup is a single file read, which is why the
published package declares a single runtime dependency (yaml) — a property
the build asserts rather than assumes. The version reported by --version is
injected at build time from package.json.

Releases are published by ClikDeploy, not by hand or by CI: package.json
holds MAJOR.MINOR, and ClikDeploy assigns the patch, stamps it, and publishes
to npm with a matching GitHub release (see packages/vscode/PUBLISHING.md).

License

MIT