opencode-with-claude's config key depends on your OpenCode generation, and a wrong one is ignored

The config key depends on the generation, and a wrong one is ignored

OpenCode has two generations with different configuration keys, and this plugin supports both from a single package. The 1.x line uses a `plugin` array and per-provider `options`; OpenCode 2 uses `plugins` and per-provider `settings`. So the 1.x block is:

{
  "$schema": "https://opencode.ai/config.json",
  "plugin": ["opencode-with-claude"],
  "provider": {
    "anthropic": {
      "options": {
        "baseURL": "http://127.0.0.1:3456",
        "apiKey": "dummy"
      }
    }
  }
}

and the OpenCode 2 equivalent changes two key names and appends a version segment to the URL, `plugins`, `providers`, `settings` and `http://127.0.0.1:3456/v1`.

The warning attached to this is the important part: a block written for the other generation is silently ignored. There is no error, no warning in the output, and no proxy starting, so the symptom a new user sees is a plugin that appears installed and does nothing. The plugin entry itself is the key that differs, and it is the one that decides whether the rest of the file is read.

That is why the package carries both plugin SDKs as development dependencies, one pinned to a 1.x version and one to a 2.0 release: supporting both generations means building against both.

The URL you type is documentation, not configuration

Both configuration examples carry `"apiKey": "dummy"` and a fixed localhost port, and the page says plainly that the base URL is only a placeholder: the plugin rewrites every Anthropic request to whatever port its own proxy actually received.

That is what makes several instances work at once. Each OpenCode process gets its own proxy, on port 3456 when that port is free and on an operating-system assigned port otherwise, and the plugin substitutes the real one into outgoing requests. Project instances inside a single process share that process's proxy rather than starting their own, including when two of them initialise the plugin at the same moment.

So the port in the config file is never the port your traffic uses, and two OpenCode windows can run side by side without colliding. The placeholder has to be there because the configuration format requires a base URL field, not because the value is read.

The proxy lifecycle is owned by OpenCode in the same way. Start OpenCode and the proxy comes up with it; quit and it stops. The stated benefit is having one process to think about rather than two, and the comparison is explicit: there is no separate proxy command line and no container to manage.

A Homebrew install needs a file path where npm takes a name

The two supported install methods are one command each, and they differ:

npm install -g opencode-with-claude

or `brew install ianjwhite99/tap/opencode-with-claude`, which the page recommends because the formula updates through `brew upgrade` instead of a global npm update.

The configuration then diverges. With npm, the plugin entry is the package name. With Homebrew, the entry has to be a path to the installed file:

"plugin": ["file:///opt/homebrew/opt/opencode-with-claude/libexec/lib/node_modules/opencode-with-claude/dist/index.js"]

The stated reason is that the Homebrew path is stable across upgrades and `brew info opencode-with-claude` prints it. The cost is that the same configuration file is wrong for one install method and right for the other, and on Linux or Intel macOS the prefix has to be changed again, since `/opt/homebrew` is the Apple-silicon default while other machines use whatever `brew --prefix` reports.

Updating is also split. Homebrew goes through `brew upgrade`, with a release workflow that bumps the formula in a separate tap repository after every npm publish, so `brew update && brew upgrade` tracks releases. npm goes through `npm update -g`, with a cache caveat.

Two runtime dependencies are pinned exactly, and two are not

The manifest has two runtime dependencies and both are exact: the proxy itself at version 1.79.0 with no range, and the prompt-scrubbing plugin at 0.2.0. The page confirms the intent, saying that each plugin release pins one exact proxy version.

That is a deliberate choice for a component sitting in the request path, and it has a consequence worth naming: the proxy moves only when the plugin moves, so a proxy bug fix arrives as a plugin release rather than as an independent update.

The development dependencies are looser in an inconsistent way. The two plugin SDKs are pinned differently from each other, one with a caret range and one at an exact 2.0 release, which mirrors the two generations the package targets. TypeScript is a major version ahead of what most projects carry, and the test scripts use Node's type-stripping flag to run `.mjs` test files directly rather than compiling them first.

The published tarball contains one thing, a `dist` directory, and the prepublish hook builds before publish. The repository also carries a Bun lockfile at the root while both install paths are npm and Homebrew, so there are three package managers in play for one plugin.

The plugin removes its own fingerprints from the prompt it forwards

This is the part to read carefully, because it changes what leaves your machine.

When the proxy's default client prompt pass-through is enabled, the plugin runs OpenCode-identifying prompt fingerprints through a separate scrubbing package before forwarding the request. The description is precise about the boundary: user context such as an `AGENTS.md` and configured instructions is preserved, while the working directory is passed through the process environment rather than the prompt.

The reason given is session handling. The plugin adds explicit session headers on outgoing calls so the proxy does not have to infer sessions from fingerprints alone, and it keeps OpenCode's hidden title and summary requests off the session's turn lease so the first message of a fresh session does not race them.

So there are two distinct things happening: traffic is made less identifiable as OpenCode traffic, and session attribution is made explicit rather than inferred. The first is a fingerprint change applied to your prompts; the second is a race condition the author fixed. A reader who cares what their agent's prompt looks like on the wire should assume it is not byte-identical to what OpenCode generated, and should say so explicitly.

The plugin also declines to edit the proxy's SDK feature file itself; that file belongs to the proxy's own configuration and is read lazily on every request.

Profiles, a spend cap, and a fallback when the config is broken

The plugin reads the same configuration files the standalone proxy command reads, so accounts and behaviour can be managed without leaving OpenCode. Profiles live in one file as a JSON array, each with an id and a configuration directory, or a token type holding an OAuth token obtained from the proxy's own setup command.

A second file selects which profile is active for requests that do not carry an explicit header. The fallback behaviour is specified: if the saved id is not in the profiles file, or the file is missing, the plugin logs a warning and uses the first configured profile.

A third file holds adapter keys, and it is read lazily on every request so an edit takes effect without restarting the proxy. The example shows three: memory on, thinking enabled, and a maximum budget in dollars set to 0.5.

Three environment variables override the files for parity with the command line: one for the profile array, one for the default profile, and one that points at your own build of the proxy instead of the bundled one.

The failure policy is the sentence to remember: malformed or missing files never crash the plugin. Parse and input-output failures go to OpenCode's plugin log and the plugin falls back to no-profile mode. That is a good default, and it also means a typo in a config file degrades quietly rather than stopping work.

OpenCode caches plugins by name, so an upgrade can need a directory deleted

The npm update path has a caveat that is worth knowing before you file a bug. OpenCode caches plugins it installs by package name, so a newly published version is not always picked up. The documented remedy is to clear the cached copy and restart:

npm update -g opencode-with-claude

with the cache directory being `~/.cache/opencode/node_modules/opencode-with-claude`. So an update that appears to do nothing is a known state rather than a broken install, and the fix is to delete a directory inside another tool's cache.

The rest of the operational picture is small. Authentication is one-time and goes through the official command line client, installed globally or as a Homebrew cask, followed by a login command. The alternative is the token profile type for a headless setup.

Release numbering is dense: v1.11.1 and v1.11.0 were published on the same day, about twenty-five minutes apart, after v1.10.4 the week before. The manifest is at 1.11.1, so the tag and the manifest agree, and the last push on the branch is dated 2026-09-30, the same day as the newest release.

Editorial conclusion

Use it if you want your Claude subscription reachable from OpenCode and would rather not supervise a second process, and read the fingerprint-scrubbing section before you adopt it, since the plugin rewrites outbound prompts on your behalf. Two things to check first. The config keys differ between OpenCode generations and a block written for the other one is ignored without an error, so confirm your generation before concluding anything is broken. And the install method changes your config: a Homebrew install needs a file path where an npm install takes the package name.

Frequently asked questions

Official sources

1. ianjwhite99/opencode-with-claude on GitHub
2. License: MIT
3. Project website
4. README
5. Releases