# OpenClaude: a terminal coding agent that does not lock you to one model provider > OpenClaude is a TypeScript CLI that runs coding-agent workflows against OpenAI-compatible APIs, Gemini, GitHub Models, Codex OAuth, Ollama and other backends. It is a provider-switching layer, not a new model, and the README is thinner on rollback and sandboxing than on setup. **Gitlawb/openclaude** — runs anywhere. uses anything - Repository: https://github.com/Gitlawb/openclaude - Website: https://openclaude.gitlawb.com - Stars: 33,484 · Forks: 9,099 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/gitlawb-openclaude ## The problem OpenClaude actually solves: one terminal, many model backends Most coding-agent CLIs are built around one vendor. If you want to try a Gemini model on Monday and a local Ollama model on Tuesday, you usually end up with two tools, two sets of slash commands, two configuration files, and two ideas of what a tool call looks like. OpenClaude's stated goal is to collapse that. The README describes it as an "open-source coding-agent CLI for cloud and local model providers" and lists OpenAI-compatible APIs, Gemini, GitHub Models, Codex OAuth, Codex, Ollama and Atomic Chat among the supported backends. The audience is narrower than the tagline suggests. This is for engineers who already hold API keys or run a local inference server and who are comfortable in a terminal. It is not a hosted product, and the README does not describe a web UI for coding work. The npm package description goes further, claiming "OpenAI, Gemini, DeepSeek, Ollama, and 200+ models", but the README itself does not enumerate those 200 models, so treat that number as a package-metadata claim rather than a documented list. The more interesting part of the pitch is what stays constant. Prompts, tools, agents, MCP, slash commands and streaming output are meant to be identical regardless of which backend answers. That is the real product: a stable interface, with the model as a swappable component. ## How the provider layer and the tool loop fit together The repository layout tells you most of the architecture. The entry point is bin/openclaude, which runs the built bundle at dist/cli.mjs. Source lives in src/, the build script is scripts/build.ts, and the package is ESM ("type": "module"). There is also a second entry point, a ./sdk export in package.json that points at dist/sdk.mjs with types at src/entrypoints/sdk.d.ts, so the same machinery can be driven programmatically rather than only from the terminal. Provider selection is a first-class concept, not an environment variable you set and forget. The README mentions "Guided provider setup and saved profiles with /provider", and the package scripts confirm it: there are separate development launchers for codex, openai, gemini, ollama and atomic-chat, plus profile scripts named profile:init, profile:recommend and profile:auto. A profile, in other words, is a saved bundle of provider settings that the CLI can select at launch. Configuration is deliberately explicit. The .env.example file states that "OpenClaude does not automatically load .env files to protect you from accidental key exposure in untrusted repositories", and that you must pass the file yourself with --provider-env-file. The same file notes that the loader "accepts OpenClaude provider/setup variables and rejects process-control variables such as PATH, NODE_OPTIONS, and LD_PRELOAD". That rejection list is a sensible boundary: it stops a checked-in .env from hijacking how Node starts. The tool loop itself is what you would expect from this class of CLI. The README lists bash, file tools, grep, glob, agents, tasks, MCP and web tools. The Dockerfile is the clearest evidence of what those tools need at runtime: the runtime stage installs git and ripgrep with the comment "many CLI tool operations depend on them". If either binary is missing, the corresponding tools are the ones that break. ## Installing OpenClaude and running a first prompt The README's Quick Start puts installation under npm. Node.js 22.0.0 or newer is required for npm installs and runtime; Bun is only needed when building from source. The package name is @gitlawb/openclaude and the installed binary is openclaude. ```bash npm install -g @gitlawb/openclaude openclaude --version ``` After the global install, openclaude --version should print the installed version. The current release in the repository is v0.30.0, tagged on 2026-08-31. If you would rather not install globally, the repository ships a Dockerfile. It builds on node:22-slim, uses the Bun version pinned in .bun-version, runs bun run build, prunes dev dependencies, then installs git and ripgrep in the runtime image and drops to the non-root node user. The container entry point is node /app/bin/openclaude. ```dockerfile FROM node:22-slim WORKDIR /app COPY --from=build /app/dist/cli.mjs dist/cli.mjs COPY --from=build /app/bin/ bin/ COPY --from=build /app/node_modules/ node_modules/ COPY --from=build /app/package.json package.json RUN apt-get update && apt-get install -y --no-install-recommends git ripgrep USER node ENTRYPOINT ["node", "/app/bin/openclaude"] ``` For credential handling, the documented path is a .env file that you pass explicitly. Copy the example, fill in only the section for the provider you intend to use, and hand it to the CLI: ```bash cp .env.example .env openclaude --provider-env-file .env ``` The Anthropic section of .env.example shows the shape of these variables: ANTHROPIC_API_KEY, an optional ANTHROPIC_MODEL, an optional ANTHROPIC_BASE_URL, and ANTHROPIC_AUTH_TOKEN for custom Bearer endpoints. Only one provider's block needs to be filled in. Once the CLI is running, the first real step is provider setup. The README points at /provider for guided setup and saved profiles. In development builds the equivalent shortcuts exist as separate scripts, for example bun run dev:ollama for a local backend and bun run dev:openai for OpenAI. Pick one provider, confirm a single prompt round-trips, and only then add a second profile. ## Where OpenClaude gets thin: rollback, safety answers, and licence ambiguity The README does not document rollback. There is no described way to undo a file edit or a shell command that the agent performed, and no snapshot or checkpoint mechanism is mentioned. For a tool that ships bash and file tools, that is the gap that matters most, and the README is simply silent on it. If your workflow depends on being able to reverse an agent action, verify that behaviour yourself before letting it near a repository you care about. The safety question is also not answered in the documentation. There is no documented sandbox, no permission prompt description, and no statement about which commands the agent will or will not run. The Dockerfile's non-root node user is a container-level precaution, not a policy for the agent's own tool calls. The repository does carry a SECURITY.md, but its contents are not reproduced here, so the reporting process is the only thing that can be assumed to exist. Licensing is genuinely confusing. The README badge links to LICENSE with the label MIT, but the repository's licence field is NOASSERTION, which is what GitHub reports when it cannot match the file to a known licence. Those two signals disagree. Read the LICENSE file in the repository root rather than trusting either the badge or the metadata. Finally, the project is moving quickly. Releases v0.29.0 and v0.29.1 landed on the same day, 2026-08-19, and v0.30.0 followed on 2026-08-31. The last push to main was on 2026-09-09. That cadence means configuration keys and provider behaviour can shift between minor versions, and the README does not promise stability for any of them. ## How OpenClaude differs from a single-vendor agent CLI The obvious alternative is a vendor's own first-party agent CLI, which typically ships with the model it was written for. The difference in approach is structural rather than cosmetic. A first-party CLI can assume one API shape, one authentication flow, and one set of model capabilities, so it can expose features that only make sense for that model. OpenClaude instead normalises several backends behind one tool surface, which is why it needs a provider abstraction, saved profiles, and a --provider-env-file loader at all. That trade cuts both ways. You gain portability: the same prompts, agents and MCP configuration keep working when you switch from a hosted API to a local Ollama model, which matters if you want to keep sensitive code off a remote endpoint. You lose the ability to lean on provider-specific behaviour that has no equivalent elsewhere, and you inherit whatever the lowest common denominator of the supported backends happens to be. A tool that works everywhere rarely exploits everything. The local-backend case is the one where OpenClaude is hardest to replace. If your reason for using a coding agent is that the code cannot leave your machine, a hosted-only CLI is not an alternative at all, and the Ollama path is the whole point. ## Maintenance, upgrades and what the release cadence costs you The project is not archived, and the last push to main was on 2026-09-09. Release Please configuration is present (.release-please-manifest.json and release-please-config.json), and the tags follow semver: v0.29.0, v0.29.1, v0.30.0. That is a conventional setup, and it means upgrades arrive as ordinary npm version bumps. The cost is not in the upgrade command, it is in what the version bump can change. Two patch releases on a single day, followed by a minor release twelve days later, is a fast enough cadence that a saved provider profile written for v0.29.x may not carry over unchanged. The README does not document a migration path between versions, and CHANGELOG.md is the only place that would describe breaking changes; its contents are not reproduced here. On the licence: the README badge says MIT, the repository metadata says NOASSERTION. Those are different answers to the same question, and the difference matters if you plan to redistribute the CLI or embed its SDK export in a product. Reading LICENSE in the repository root is the only reliable way to settle it. Nothing here is legal advice. The dependency footprint is worth noting too. The Dockerfile installs git and ripgrep at runtime because tool operations depend on them, so any environment where you deploy OpenClaude needs those binaries present, not just Node.js 22. ## Conclusion Adopt OpenClaude if you already pay for one or more model APIs and want a single terminal workflow over them, or if you want to point a coding agent at a local Ollama model without changing tools. Skip it if you need a documented rollback path, a stated security model for shell execution, or a licence you can read at a glance, because the repository is tagged NOASSERTION even though the README badge says MIT. Before committing, install it on Node.js 22, run /provider against one cheap key, and read LICENSE in the repository root to confirm which terms actually apply. ## FAQ ### What is OpenClaude? It is an open-source coding-agent CLI for cloud and local model providers, written in TypeScript. The README describes one terminal-first workflow covering prompts, tools, agents, MCP, slash commands and streaming output across multiple backends. ### How do I install OpenClaude? The README's Quick Start installs it from npm as @gitlawb/openclaude, and Node.js 22.0.0 or newer is required for npm installs and runtime. Bun is only needed when building from source. ### How do I use OpenClaude? Install the CLI, then use /provider for guided provider setup and saved profiles. Provider credentials can be supplied through a .env file passed explicitly with --provider-env-file. ### How do I install OpenClaude on Windows? The repository includes ANDROID_INSTALL.md, docs/windows-aliases-and-launchers.md and a scripts/windows/openclaude-aliases.ps1 file, and package.json ships the Windows alias script in its files list. The README excerpt does not give the Windows steps themselves. ### Is OpenClaude free to use? The README badge labels the licence MIT, but the repository's licence field is NOASSERTION, so the two disagree. The CLI itself is open source; any model API you connect it to is billed by that provider, and the README does not state otherwise. ### How do I set up OpenClaude? Copy .env.example to .env, fill in the variables for one provider, and pass the file with openclaude --provider-env-file .env. The loader accepts provider and setup variables but rejects process-control variables such as PATH, NODE_OPTIONS and LD_PRELOAD. ## Sources - [Gitlawb/openclaude on GitHub](https://github.com/Gitlawb/openclaude) - [Issues](https://github.com/Gitlawb/openclaude/issues) - [Project website](https://openclaude.gitlawb.com) - [README](https://github.com/Gitlawb/openclaude/blob/main/README.md) - [Releases](https://github.com/Gitlawb/openclaude/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gitlawb-openclaude