Atomic Agent mascot as a locksmith handing personal lockboxes to a queue of coding agent characters, while a cracked cloud vault spills golden keys behind it
Comparison

OpenCode Alternatives After the Console Breach: 9 Coding Agents and Where They Keep Your API Keys

Published
Reading time
15 min read

OpenCode Console may have exposed provider keys on Oct 17. We checked 9 coding agents for where API keys live, telemetry and approvals.

This guide compares nine OpenCode alternatives for people who run a coding agent in the terminal with their own API keys: Atomic Agent, Goose, Codex CLI, GitHub Copilot CLI, Crush, Pi, Qwen Code, Cline CLI and Kilo CLI. After the OpenCode Console breach, the question most people are asking is simple: where does each tool keep my provider keys, and does any vendor hold a copy? So for every tool we checked the exact key file, keychain support, any hosted key vault or gateway, the telemetry default and how it handles approvals.

What happened at OpenCode. On October 17, 2026, OpenCode posted that it “had a security breach last night related to a large scale distillation attack that impacted 1.4% of OpenCode Console users” (via IBTimes; Hacker News thread). The breach hit the hosted Console, a web workspace where users could save provider keys. The customer email said that “Third party provider keys (eg OpenAI, Anthropic) saved in your workspace may have been exposed” (via DEV Community). Co-founder dax drew the line for CLI users: “note this is the OpenCode Console, not OpenCode itself, those keys never come to us” (via IBTimes). Users have reported their own losses, including $281 on OpenAI plus $168 on Anthropic for one and $1,700 for another (Dealroom figures, via The Hacker News).

We build Atomic Agent, so it sits first. Every claim about it was checked against its code at v0.6.9 and Desktop v0.0.3 (main as of October 15, 2026), including the parts where it is weaker than the others. Everything else was checked on October 19, 2026.

Quick answer: which OpenCode alternative should you pick?

Pick by the risk that brought you here. If it is a vendor holding your keys, any of the nine works as long as you skip optional web key pages and gateways. If it is malware reading key files, Goose’s keyring default is the strongest start, and the table maps the other needs.

If you needPickWhy
No cloud API key at allAtomic Agent (ours)Default provider is a local llama-server on 127.0.0.1, no key needed
Keys in the OS keyring by defaultGooseKeyring first, plaintext only as a fallback, telemetry opt-in
A sandbox by defaultCodex CLIOS sandbox on with network off; switch key storage to keyring
GitHub integration, BYOK from env varsGitHub Copilot CLIGitHub token in the keychain, BYOK keys read from env only
The best-looking TUI with llama.cppCrushllamacpp, lmstudio and ollama provider types built in
A small agent you can rewirePiMinimal harness; keys can come from the macOS Keychain via a command
Any provider protocolQwen CodeOpenAI, Anthropic, Gemini, Vertex and Qwen protocols
The same setup as Cline in VS CodeCline CLIOne provider config across IDE, CLI and desktop
The closest thing to OpenCodeKilo CLIA fork of OpenCode; keep keys in local auth.json

For a wider list of agents built around local models, see our sister project’s roundup of the best local AI agents.

What to do first if you used OpenCode Console

If you ever saved a provider key in an OpenCode Console workspace, revoke it at the provider today, even if you did not get an email. Deleting it inside Console is not enough. Then create new keys, check usage from October 16 onward, set spend limits, give each tool its own key, and confirm the old key is dead.

  1. Revoke at the provider. Go to the OpenAI, Anthropic, Google or OpenRouter dashboard and delete the key there. Some providers acted on their own: Anthropic’s Lydia Hallie said Anthropic “revoked Claude API keys we believe were affected” (via avneeshk.me), and OpenCode’s follow-up email said “We’ve worked with OpenAI to revoke all of them and they have issued refunds” (via Hacker News).
  2. Create new keys. Do not paste them back into any hosted console.
  3. Check usage from October 16. Look for traffic you do not recognise. Affected users reported unexpected charges on OpenAI, Anthropic and Google accounts, as Infosecurity Magazine and IBTimes covered.
  4. Set spend limits in each provider dashboard. Atomic Agent has no spend cap for API-key providers, and we did not find one in most of the others, so set the provider’s limit.
  5. Use one key per tool. If one agent’s file leaks, you revoke one key and know where it came from.
  6. Confirm the old key returns 401. Send one request with it, for example curl https://api.openai.com/v1/models -H "Authorization: Bearer $OLD_KEY", and check that the provider rejects it.

OpenCode has not explained the “distillation attack” it named; a Hacker News thread says it could just as well be key reselling.

How we checked these OpenCode alternatives

We checked nine terminal coding agents on October 19, 2026, using each project’s GitHub repo, release page, docs and, where the docs were silent, source code. To make the list, a tool had to be a terminal-first coding agent, ship a release in the last 90 days, and accept your own keys for more than one provider.

For each tool we looked at five things:

  • Key path: the exact file or store where a key ends up after you log in or paste it.
  • Keychain or plaintext: whether the OS keychain is the default, an option or absent, and the file permissions where we found them.
  • Vendor-held keys or gateway: whether the vendor offers a hosted place to store your provider keys, or a gateway your traffic can go through.
  • Telemetry default: on, off or asked, and the documented off switch.
  • Approvals: what the agent does before it writes files or runs shell commands, out of the box.

Stars and release dates come from the GitHub API on October 19. We did not benchmark the agents or run them side by side.

Four tools other lists recommend did not make it. Aider’s last release is v0.86.0 from August 9, 2025. Hermes Agent is a general personal agent with a chat gateway, and we compared it in our OpenClaw alternatives guide. Gemini CLI only talks to Google models. Claude Code is built for Claude models: other models work only through an Anthropic-compatible gateway or Ollama’s own integration. It keeps its login in the macOS Keychain and falls back to ~/.claude/.credentials.json with 0600 permissions (docs). If you only use Claude, it is a solid choice, and our Claude Code alternatives post covers the open-source field around it.

A note on “plaintext”: a file with 0600 permissions is readable only by your user. That stops other users on the machine. It does not stop malware running as you, and infostealers now look for agent key files. Gen Digital reported infostealers that target the local data of Claude, Cline, Continue, Cursor and OpenCode (Amatera and Remus), plus a macOS stealer, Djinn, that adds Codex, and Symantec described one that collects coding-agent configs and tokens.

The 9 OpenCode alternatives, reviewed

All nine run in the terminal, take your own keys for several providers, and shipped a release after July 21, 2026. Each card covers where your keys live, any vendor cloud option, telemetry and approvals. The Note is the downside we would want to know before switching, and the Verdict says who should pick it.

1. Atomic Agent: best for local models with no API key

We build Atomic Agent, so read this card with that in mind and check it against the repo.

Atomic Agent is a local-first agent runtime under the MIT license, with a terminal UI and a desktop app. It runs local models, cloud models, or Fusion, where one model plans and workers execute. It has 3,405 stars; the latest releases are v0.6.9 and Desktop v0.0.3, both on October 15, 2026. Install with curl -fsSL https://atomicagent.io/install | sh, or irm https://atomicagent.io/install.ps1 | iex on Windows; the installer verifies a checksum.

  • Where keys live: in plaintext files under ~/.atomic-agent. The terminal setup wizard writes .env (for example OPENROUTER_API_KEY), and the desktop app writes the key inline in config.json. Both files are written with 0600 permissions, plus a Windows ACL for .env. config.json has been 0600 since v0.6.7; installs on v0.6.5 or earlier wrote it without that, and it may stay readable by other users until the next save. There is no OS keychain support.
  • Vendor cloud: none. There is no Atomic-hosted console, account or proxy that holds or forwards your model keys. Calls go from your machine straight to the provider, such as openrouter.ai, api.anthropic.com or api.openai.com.
  • No key at all: the default provider is a local llama-server on 127.0.0.1. The agent can manage llama.cpp for you, or use your own llama-server, and the Ollama and LM Studio presets need no key either. A keyless setup sends no Authorization header.
  • Telemetry: on by default. PostHog and Sentry events carry provider, model, token and cost data, without message content, and a scrubber filters Sentry reports. Turn it off with analytics.enabled: false in the config, which covers the terminal and the desktop app (the ATOMIC_AGENT_ANALYTICS=off variable covers the terminal only).
  • Approvals: a five-level approval ladder, level 1 by default. File edits to the agent’s own config.json or .env ask at every level below 5, and a session-wide grant cannot silence that; at level 4, shell commands are auto-approved and could still change those files. Outbound HTTP requests from its web tool do not ask by default.

Note: on key storage itself it is weaker than Goose, Claude Code and Copilot CLI: plaintext files, no keychain. It has no spend cap for API-key providers, and traces store prompts and tool output as they are, so if the agent reads a .env, that content goes to the model unredacted. Telemetry is on until you turn it off. atomic-agent uninstall removes everything, keys included.

Verdict: Choose Atomic Agent if the safest key for you is no cloud key: you want a local model as the default, with no vendor account in the path, and you are fine with keys in 0600 files when you do add a cloud provider. Download it here.

2. Goose: best for keys in the OS keyring by default

Goose started at Block and now sits in the Agentic AI Foundation at the Linux Foundation. It is Apache-2.0, has 55,437 stars and released v1.55.0 on October 16, 2026.

  • Where keys live: in the system keyring under the service name “goose”. If no keyring is available, or GOOSE_DISABLE_KEYRING is set, it falls back to plaintext ~/.config/goose/secrets.yaml (%APPDATA%\Block\goose\config\secrets.yaml on Windows), written with 0600 permissions on macOS and Linux (source).
  • Vendor cloud: none. goose gateway is a Telegram bridge and does not proxy model calls.
  • Providers and local models: about 50 providers, plus any OpenAI-, Anthropic- or Ollama-compatible endpoint; local options include Ollama, LM Studio, Ramalama and Docker Model Runner (providers doc).
  • Telemetry: opt-in, asked at first run. Data goes to PostHog; GOOSE_TELEMETRY_ENABLED=false turns it off (usage data doc).
  • Approvals: four modes: Autonomous (the default), Manual, Smart and Chat Only. In Autonomous mode it can modify and delete files without asking (permissions doc).

Note: out of the box Goose acts without asking, so switch to Manual or Smart before you point it at a real repo. And if your system has no keyring, keys land in a plaintext YAML file.

Verdict: Choose Goose if you want an OS-keyring default and dozens of providers without a vendor account.

3. Codex CLI: best for a sandbox by default

Codex CLI is OpenAI’s open-source coding agent, written in Rust under Apache-2.0. It has 129,910 stars and released rust-v0.163.0 on October 15, 2026.

  • Where keys live: by default cli_auth_credentials_store = "file", which means plaintext ~/.codex/auth.json (ChatGPT tokens, or your OpenAI API key if you log in with one) written with 0600 permissions on macOS and Linux. The other options are keyring, auto (keyring, else file) and ephemeral. OpenAI’s own docs say to “treat ~/.codex/auth.json like a password” (auth docs). Keys for custom providers are normally read from an environment variable (env_key) at runtime and never written to that file, though the discouraged experimental_bearer_token setting puts a key in plain text in config.toml (source).
  • Vendor cloud: no store for third-party keys; custom providers are called directly.
  • Local models: --oss with Ollama or LM Studio.
  • Telemetry: anonymous usage metrics to OpenAI, on by default; [analytics] enabled = false turns them off (advanced config).
  • Approvals: an OS sandbox is on by default with network off, and approval_policy controls when it asks (approvals and security).

Note: the default key file is plaintext, and it has already been a target: the codexui-android npm package stole tokens from ~/.codex/auth.json, per a Cloud Security Alliance note. Set cli_auth_credentials_store = "keyring".

Verdict: Choose Codex CLI if you want an open-source agent with a real sandbox, and you will switch key storage to the keyring.

4. GitHub Copilot CLI: best for GitHub users who keep BYOK keys in env vars

GitHub Copilot CLI is GitHub’s terminal agent. It is proprietary: the repo holds the README, license, changelog and install script, but no source. It has 11,273 stars and released v1.0.98 on October 14, 2026. BYOK works through COPILOT_PROVIDER_* environment variables.

  • Where keys live: the GitHub OAuth token goes into the OS keychain (service copilot-cli). Without a keychain, the CLI asks before saving plaintext ~/.copilot/config.json (auth docs). BYOK keys are read from environment variables; we found no step in the docs that saves them.
  • Vendor cloud: on Enterprise, enterprise owners can upload provider keys for “custom models” into GitHub’s settings and can let organization owners do the same, which means GitHub holds those keys (a public preview) (docs). Individual BYOK does not need a GitHub login at all, though you lose /delegate, the GitHub MCP server and code search (BYOK docs). Remote session sync is on by default; --no-remote turns it off.
  • Local models: Ollama through COPILOT_PROVIDER_BASE_URL=http://localhost:11434, plus vLLM and Foundry Local per the BYOK docs, with a model that supports tool calling.
  • Telemetry: on by default, including for BYOK without login. The only documented full opt-out is COPILOT_OFFLINE=true.
  • Approvals: read-only actions run on their own; writes and shell commands prompt. --allow-tool and --deny-tool fine-tune it.

Note: it is closed source, and turning telemetry fully off means offline mode, which drops the GitHub features that make it worth using.

Verdict: Choose Copilot CLI if you already live in GitHub and want keys only in env vars and the keychain.

5. Crush: best terminal UI for local model servers

Crush is the coding agent from Charmbracelet, Inc. It has 28,704 stars and released v0.98.1 on October 9, 2026. Its license is FSL-1.1-MIT, which is source-available and bans “Competing Use”, so it is not OSI open source (license).

  • Where keys live: plaintext JSON, with no keyring. Keys you paste in the UI go to ~/.local/share/crush/crush.json (%LOCALAPPDATA%\crush\crush.json on Windows), written with 0600 permissions, and OAuth tokens go in the same file (source). Environment variables work too.
  • Vendor cloud: Charm Hyper is Charm’s own optional subscription gateway, and your traffic goes through Charm when you use it. Its Enterprise plan advertises bring-your-own frontier-lab keys, and we found no documentation of how it stores them (Hyper).
  • Local models: provider types ollama, lmstudio and llamacpp are built in (README).
  • Telemetry: pseudonymous PostHog metrics, on by default, without a prompt. CRUSH_DISABLE_METRICS=1 or DO_NOT_TRACK=1 turns them off.
  • Approvals: asks before tool calls by default, with allow and deny lists in config; --yolo skips prompts.

Note: keys sit in a plaintext file next to OAuth tokens, metrics are on without asking, and the license is not OSI-approved.

Verdict: Choose Crush if you want the nicest terminal UI and first-class llama.cpp or LM Studio support, and you keep your keys in env vars.

6. Pi: best for a minimal, hackable agent

Pi is a small, extensible coding agent by Mario Zechner, acquired by Earendil Inc. on April 8, 2026 and still MIT (announcement). It has 116,373 stars and released v1.3.0 on October 15, 2026.

  • Where keys live: plaintext ~/.pi/agent/auth.json, mode 0600 in a 0700 directory. A key can instead be a shell command, such as !security find-generic-password ..., which reads it from the macOS Keychain at runtime (providers doc).
  • Vendor cloud: Radius, an optional Earendil gateway in early alpha with organization controls. Its API lists “BYOK credential providers”, and we could not confirm how it stores them. /share uploads to Radius when you are logged in, or to a GitHub gist otherwise.
  • Local models: Ollama, LM Studio, vLLM and SGLang, plus a llama.cpp guide.
  • Telemetry: install and update pings and provider attribution headers are on by default; analytics are opt-in. PI_TELEMETRY=0 turns telemetry off and PI_OFFLINE stops automatic network activity.
  • Approvals: none by design. Pi’s security doc recommends running it in a container or VM.

Note: out of the box Pi acts without asking, and plan mode and sub-agents are not built in.

Verdict: Choose Pi if you want a small agent you can rewire, you will run it in a container, and you will pull keys from your Keychain.

7. Qwen Code: best for mixing provider protocols

Qwen Code is the Qwen team’s fork of Gemini CLI, under Apache-2.0. It has 28,582 stars and released v0.25.3 on October 19, 2026. It speaks the OpenAI, Anthropic, Gemini, Vertex and Qwen protocols, and /model switches models at runtime. The free Qwen OAuth tier ended on April 15, 2026.

  • Where keys live: a key typed into /auth goes to an env block in plaintext ~/.qwen/settings.json, written with no explicit file mode, so a new file usually gets 0644. Environment variables and .qwen/.env also work; the docs headline the one-file settings.json setup but advise .qwen/.env for security (auth doc). We found keychain code for MCP tokens only.
  • Vendor cloud: none for third-party keys.
  • Local models: Ollama, vLLM and LM Studio through the openai protocol with a localhost base URL.
  • Telemetry: usage statistics are on by default and go to Alibaba Cloud’s monitoring service; code and prompts are not collected. Set privacy.usageStatisticsEnabled to false to stop it.
  • Approvals: Plan, Ask, Auto-Edit, Auto and YOLO. The interactive default is Auto, where an AI model judges each action (approval modes).

Note: keys are plaintext, statistics go to Alibaba unless you switch them off, and the default approval mode leaves the risk call to a model.

Verdict: Choose Qwen Code if you want a Gemini-CLI-style agent that takes any provider’s key.

8. Cline CLI: best for teams already on Cline in VS Code

Cline by Cline Bot Inc. shares one provider config across its IDE extension, CLI and desktop app, under Apache-2.0. It has 70,550 stars and released cli-v3.0.73 on October 17, 2026. cline kanban runs parallel agents in git worktrees.

  • Where keys live: plaintext ~/.cline/data/settings/providers.json, mode 0600 in a 0700 directory, with no keychain (source). Passing -k on a run also saves the key.
  • Vendor cloud: no cloud store for individual BYOK keys. Enterprise remote config sets providers and models, while members’ keys stay “stored locally” (docs). Cline’s default provider is its own pay-as-you-go gateway, so your traffic goes through Cline unless you pick a direct provider.
  • Local models: Ollama and LM Studio (docs).
  • Telemetry: on by default, including for BYOK. Opt out with "telemetryOptOut": true in ~/.cline/data/settings/global-settings.json.
  • Approvals: the CLI’s --auto-approve defaults to true, and there is no built-in allow or deny list for shell commands (CLI reference).

Note: out of the box Cline CLI acts without asking. For enterprise users, the CLI can also write org settings into .cline/enterprise/ in the project folder, and the docs say to add it to .gitignore.

Verdict: Choose Cline CLI if your team already uses Cline in VS Code and wants the same providers in the terminal.

9. Kilo CLI: best for the closest OpenCode workflow

Kilo CLI is a fork of OpenCode by Kilo Code, under MIT. Kilo’s docs now carry the banner “Kilo has been acquired by Anaconda” (source). It has 27,659 stars; the latest stable release is v7.8.12 from October 15, 2026. It can also import Claude Code and Codex sessions.

  • Where keys live: plaintext ~/.local/share/kilo/auth.json, mode 0600 (source).
  • Vendor cloud: yes, optional. You can paste Anthropic, OpenAI, Google, Bedrock, Azure and other keys into a web BYOK page at app.kilo.ai, and requests then go through the Kilo Gateway with your key (BYOK docs). The gateway page claims encrypted-at-rest storage. This is the same shape as OpenCode Console.
  • Local models: Ollama and LM Studio (docs).
  • Telemetry: PostHog, on by default; KILO_TELEMETRY_LEVEL=off turns it off.
  • Approvals: allow, ask or deny per tool. Most tools default to allow, and reading .env asks (docs).

Note: if you are leaving OpenCode because of the Console, the web BYOK page has the same shape: the vendor stores a copy of your key and serves it through its gateway. Out of the box Kilo also allows most tools without asking, and telemetry is on.

Verdict: Choose Kilo CLI if you want OpenCode’s workflow back today, and you keep keys in the local auth.json, never in the web BYOK page.

OpenCode alternatives compared: keys, telemetry, local models

The table compares the nine, with OpenCode’s CLI as the baseline. A keyring protects against local malware, while a vendor web page puts a second copy of your key in someone else’s database. Only Kilo offers a personal web page for your provider keys; Cline defaults to its own gateway, and Kilo, Crush and Pi run optional ones.

ToolWhere keys liveOS keychain?Vendor stores your keys?Vendor gateway?Telemetry defaultLocal modelsLicense
Atomic Agent~/.atomic-agent/.env or config.json (0600)NoNoNoOn (analytics.enabled: false)Local llama-server by default; Ollama, LM StudioMIT
GooseOS keyring; fallback ~/.config/goose/secrets.yaml (0600)Yes, defaultNoNoOpt-in, asked at first runOllama, LM Studio, Ramalama, Docker Model RunnerApache-2.0
Codex CLI~/.codex/auth.json (0600)Optional (keyring)NoChatGPT login traffic via OpenAIOnOllama, LM StudioApache-2.0
Copilot CLIGitHub token in keychain; BYOK from envYes, for GitHub loginEnterprise and org owners (custom models, preview)Copilot subscription models via GitHubOn (COPILOT_OFFLINE=true)Ollama, vLLM, Foundry LocalProprietary
Crush~/.local/share/crush/crush.json (0600)NoEnterprise only (Hyper BYOK), storage not documentedHyper (optional)OnOllama, LM Studio, llama.cppFSL-1.1-MIT
Pi~/.pi/agent/auth.json (0600)Via a Keychain commandUnclear (Radius BYOK, alpha)Radius (optional, alpha)Pings on, analytics opt-inOllama, LM Studio, vLLM, SGLang, llama.cppMIT
Qwen Code~/.qwen/settings.json (no explicit mode) or .qwen/.envNoNoNoOnOllama, vLLM, LM StudioApache-2.0
Cline CLI~/.cline/data/settings/providers.json (0600)NoNoCline provider (default)OnOllama, LM StudioApache-2.0
Kilo CLI~/.local/share/kilo/auth.json (0600)NoYes, optional web BYOK pageKilo GatewayOnOllama, LM StudioMIT

For the baseline: OpenCode’s own CLI keeps provider keys on your machine, in plaintext and with no keychain. The current release, v1.19.3, writes them to ~/.local/share/opencode/auth.json with 0600 permissions (source), and the V2 line, published so far only as tags while npm latest is still 1.19.3, stores them in the local SQLite database opencode.db, created with 0600 permissions, importing the old file (V2 docs). The Console worked differently: its docs say “Console stores the credential and serves each provider through its gateway” (Console docs). That stored copy is what may have been exposed.

Frequently asked questions

FAQ

Leaving OpenCode after the Console breach, answered.

  • Is OpenCode safe to use after the breach?

    Yes, the local OpenCode CLI was not what got breached. The incident hit the hosted OpenCode Console, which stores provider keys and serves them through its gateway. The CLI keeps keys on your machine with no keychain: v1.19.3 writes a plaintext auth.json with 0600 permissions, and the V2 pre-release stores them in a local SQLite database with 0600 permissions. Either way, any process running as you, including infostealers, can read them.

  • Which coding agent stores API keys most securely?

    Goose, by default. It writes provider keys to the OS keyring and falls back to a plaintext file only when no keyring is available. Codex CLI can use the keyring with one setting. Claude Code and Copilot CLI keep their own logins in the keychain. Atomic Agent stores keys in plaintext files with 0600 permissions and has no keychain support.

  • Does Atomic Agent need an API key?

    No. Its default provider is a local llama-server on 127.0.0.1, and the Ollama and LM Studio presets need no key; a keyless setup sends no Authorization header. You only need a key for a cloud provider such as OpenRouter, Anthropic or OpenAI, and that key goes into a plaintext file under ~/.atomic-agent with 0600 permissions.

  • Can I import my OpenCode setup?

    No, not into Atomic Agent. It has no OpenCode importer. It imports from Claude Code (skills, memory, MCP servers, sessions and, if you opt in, your ANTHROPIC_API_KEY), Codex (skills, memory, sessions and, if you opt in, your OPENAI_API_KEY), Hermes, OpenClaw, Pi and Oh-My-Pi. Kilo CLI is a fork of OpenCode, so its workflow is the most familiar if you are switching.

  • Should I rotate my keys if I only used the OpenCode CLI?

    It is optional. OpenCode said the breach affected Console users, and its co-founder dax wrote that keys in the CLI never reach OpenCode. Rotating is still cheap insurance, and it is mandatory for any key you ever saved in a Console workspace.

  • Which OpenCode alternatives send telemetry by default?

    Eight of the nine send something by default. Atomic Agent, Codex CLI, Copilot CLI, Crush, Qwen Code, Cline CLI and Kilo CLI send usage data until you switch it off, and Pi sends install and update pings with analytics left opt-in. Goose is the exception: it asks for consent at first run.

Bottom line: matching the tool to your risk

Start from the risk that brought you here. If it is a vendor holding your keys, all nine keep keys on your machine; with Kilo, Crush and Pi, skip their optional gateways, and with Cline, pick a direct provider over its default gateway. Against malware reading key files, Goose’s keyring default is strongest; Codex needs one setting.

For the least change, Kilo CLI is an OpenCode fork; keep keys in its local auth.json. For a sandbox around every command, Codex CLI. For GitHub, Copilot CLI.

If you would rather not hold a cloud key at all, try Atomic Agent. Its default model runs on a local llama-server, so there is no key to leak until you add a cloud provider. When you do, the key sits in a 0600 file under ~/.atomic-agent, without keychain support, and telemetry stays on until you set ATOMIC_AGENT_ANALYTICS=off. Weigh that against Goose’s keyring if key storage is your main concern.

Whatever you pick, do the provider-side work too: one key per tool, a spend limit on each, and a quick check that every old key now returns 401.


Release dates, versions, licenses and star counts were checked against the GitHub API and each project’s documentation on October 19, 2026. Atomic Agent claims were checked against its source code at v0.6.9 and Desktop v0.0.3 (main as of October 15, 2026). Quotes about the breach reached us through the linked news reports. We did not benchmark these agents or run them side by side.


Get new posts
by email

One email when we post something new.

Share
Written by
Nadya Dudka Product, Atomic Agent
Andrew Dyuzhov SEO and growth

Run your local agent
in one click