Skip to content

BUG: Directory paths containing "opencode" are displayed as "Claude" when using Anthropic models #10567

Closed as not planned
Closed as not planned
BUG: Directory paths containing "opencode" are displayed as "Claude" when using Anthropic models#10567
Assignees
rekram1-node

Description

@deanbrittain
deanbrittain
opened on Jan 25, 2026
Image

Description
OpenCode performs a global string replacement of "opencode" → "Claude" in directory paths, but only when using Anthropic/Claude models. This appears to be part of the Claude Code compatibility/branding layer but incorrectly transforms user-controlled directory names.

Steps to Reproduce

  1. Create a directory containing "opencode" in the name:
    mkdir ~/Documents/opencode11223opencode
    cd ~/Documents/opencode11223opencode

  2. Start opencode with an Anthropic/Claude model:
    opencode

  3. Ask the AI: "What does my env info say?"

  4. Observe the working directory in the response

Expected Behavior
The working directory should display the actual directory name:
Working directory: /Users/username/Documents/opencode11223opencode

Actual Behavior
When using Anthropic/Claude models, the directory name is transformed:
Working directory: /Users/username/Documents/Claude11223Claude
The replacement appears to be:

  • Case-insensitive: opencode → Claude
  • Global: All instances are replaced
  • Model-specific: Only affects Anthropic models

Evidence
Test Results

Model Used Directory Name Displayed As Status
GPT-4.5 opencode11223opencode opencode11223opencode ✅ Correct
Claude Sonnet 4.5 opencode11223opencode Claude11223Claude ❌ Wrong
Screenshot
(Attach the screenshot showing Claude11223Claude)

Environment

  • OpenCode Version: 1.1.35
  • OS: macOS (darwin)
  • Shell: zsh
  • Installation Method: Homebrew

Investigation Findings
What I Tried

  1. Environment variables (no effect):
    export OPENCODE_DISABLE_CLAUDE_CODE=true
    export OPENCODE_DISABLE_CLAUDE_CODE_PROMPT=true
    export OPENCODE_DISABLE_CLAUDE_CODE_SKILLS=true

  2. Binary analysis - Found Anthropic-specific code:
    function header(providerID) {
    if (providerID.includes("anthropic"))
    return [anthropic_spoof_default.trim()];
    return [];
    }

  3. The Instance.directory value itself is correct (verified by checking with GPT models)
    Root Cause
    The replacement happens during Anthropic-specific system prompt construction, likely as part of the Claude Code compatibility layer. The exact replacement code could not be located in binary strings, suggesting it may be:

  • In compiled/minified code
  • Applied via a plugin hook
  • Part of a larger prompt transformation

Impact
Severity: Medium
User Impact:

  • Confuses users about their actual working directory
  • Could cause issues if users rely on the AI's understanding of the path
  • Breaks the principle that branding should not affect user data/paths
    Affected Users: Anyone using:
  • Anthropic/Claude models
  • Directory names containing "opencode"

Suggested Fix
The Claude Code branding compatibility should:

  1. Only affect UI/prompt text that describes the tool itself
  2. Never transform user-controlled data like directory paths, file names, or content
  3. Respect the OPENCODE_DISABLE_CLAUDE_CODE flag for all branding transformations
    Proposed solution:
  • Remove the global string replacement for Anthropic models
  • OR scope the replacement to only specific parts of the system prompt header
  • OR make it respect the existing disable flags

Workaround
Until fixed, users can:

  1. Avoid naming directories with "opencode" in the name
  2. Use non-Anthropic models (GPT, etc.) when working in such directories

Related Issues

Additional Context
The transformation preserves case patterns:

  • opencode → Claude
  • OpenCode → Claude
  • OPENCODE → CLAUDE (assumed based on pattern)
    This suggests a regex-based replacement like /opencode/gi is being applied.

Activity

  1. github-actions
    assigned
    rekram1-node
    on Jan 25, 2026

  2. github-actions commented on Jan 25, 2026

    @github-actions
    github-actionsBot
    on Jan 25, 2026 – with GitHub Actions
    Contributor

    This issue appears to be unique - no exact duplicates found in the issue tracker. However, several related issues exist in the Claude Code compatibility area that may provide context:

    These issues suggest a broader pattern of Anthropic/Claude-specific behavior differences in the system prompt construction layer.

  3. NamedIdentity commented on Feb 3, 2026

    @NamedIdentity
    NamedIdentity
    on Feb 3, 2026

    I can confirm this issue. it has been persistent for many weeks.

    In addition to causing failures of commands like directory searches or changes, or causing the agent to output documents into a "claude" folder instead of the projects directory, when performing git commits in folders with 'opencode' in the directory path, in test builds using XDG it causes a bun crash which requires restarting open code.

    efforts to use AGENTS.md instructions to inform the agent of it's project directory, or that it has been improperly hallucinating directory paths containing opencode, and other system instructions meant to try to correct model behavior, have failed.

  4. thominj commented on Feb 21, 2026

    @thominj
    thominj
    on Feb 21, 2026

    Confirming the issue as well - this was very difficult to track down, thank you for filing the issue.

  5. wetlandscapes commented on Feb 23, 2026

    @wetlandscapes
    wetlandscapes
    on Feb 23, 2026

    +1, I’m seeing the same class of bug on v1.2.10 with Anthropic/Claude flows.
    In my repo, the real path is /home/<user>/working/opencode-review, but Claude-facing env context has reported /home/<user>/working/Claude-review (non-existent). This then cascades into wrong artifact paths like docs/Claude/... instead of docs/opencode/....
    Key point: opencode session/project metadata on disk still shows the correct directory (.../opencode-review), so this looks like a runtime prompt/context injection rewrite issue in the Claude path, not a local repo/config misconfiguration.
    Here is an example repo where the issue occurs: https://github.com/wetlandscapes/agentic-code-review/tree/main.

  6. gotgenes commented on Feb 23, 2026

    @gotgenes
    gotgenes
    on Feb 23, 2026

    Root cause

    The rewriting happens server-side on Anthropic's API, not in OpenCode. In provider.ts (~line 126), OpenCode unconditionally sends anthropic-beta: claude-code-20250219,... with every Anthropic request. Anthropic's server sees that flag and rewrites opencode → claude/Claude in the entire system prompt — including user-provided AGENTS.md content and Instructions from: paths.

    There's no string replacement in OpenCode's source. You can verify: anthropic.txt says "You are OpenCode" but the model receives "You are Claude Code".

    OPENCODE_DISABLE_CLAUDE_CODE=1 doesn't help — it only controls CLAUDE.md/skills file loading, not the server-side rewriting. Switching auth methods doesn't help either; the beta header is sent regardless.

    Workaround

    I developed agent instructions that survive the rewriting. Key techniques:

    1. Split the word: Write `open` + `code` instead of the joined word — the rewriter won't match it.
    2. Runtime path discovery: Instruct agents to ls ~/.config/ | grep -i open (etc.) instead of hardcoding paths.
    3. Explicit distrust: Tell the model not to trust any claude/Claude paths in its system prompt.

    Full implementation in my dotfiles: https://github.com/gotgenes/dotfiles — see the "Path Rewriting Warning" sections in AGENTS.md and private_dot_config/opencode/agents/retrospective.md.

    Suggested fix

    A flag to remove claude-code-20250219 from the beta header (while keeping interleaved-thinking and fine-grained-tool-streaming) would let users opt out of the rewriting entirely.

  7. gotgenes
    added a commit that references this issue on Feb 23, 2026

    Rewrite agent instructions to survive Anthropic server-side path rewr…

    dfafbff

  8. eXamadeus commented on Feb 25, 2026

    @eXamadeus
    eXamadeus
    on Feb 25, 2026
    Contributor

    The rewriting happens server-side on Anthropic's API, not in OpenCode

    I'm like 99% sure that's not true. I've never seen it, anyway.

    That said, there is still rewriting happening in the opencode-anthropic-auth plugin which most of us use without knowing it. Check out ~/.cache/opencode/node_modules and see if you have opencode-anthropic-auth/ in there.

    I forked the repo (after they shut it down) and applied a fix. Now you can add "plugin": ["@ex-machina/opencode-anthropic-auth"] and it will stop rewriting your directories. Go get em tiger!

    Note

    The fix is dead simple. Someone added a simple rewrite for OpenCode -> Claude at some point in the past. Turns out that doesn't matter and you can just remove it entirely.

    Anthropic doesn't care if it sees OpenCode in the system prompt. Why would they? If they blocked or banned prompts on that it would massively decrease the value of their product. And they would end up banning legitimate use cases.

    Image

  9. gotgenes commented on Feb 27, 2026

    @gotgenes
    gotgenes
    on Feb 27, 2026

    Thanks for your reply @eXamadeus!

    The rewriting happens server-side on Anthropic's API, not in OpenCode

    I'm like 99% sure that's not true. I've never seen it, anyway.

    The rewriting happens server-side on Anthropic's API, not in OpenCode

    I'm like 99% sure that's not true. I've never seen it, anyway.

    My apologies, I investigated using OpenCode and it led me here and I rage-allowed my agent to post the GitHub comment.

    That said, there is still rewriting happening in the opencode-anthropic-auth plugin which most of us use without knowing it. Check out ~/.cache/opencode/node_modules and see if you have opencode-anthropic-auth/ in there.

    I forked the repo (after they shut it down) and applied a fix.

    I'm late to the AI agent party, and I'm using OpenCode because I followed the Remix circles, saw @thdxr is involved in this, and said, "I'll start with OpenCode, then." I tried finding the origin of the fork and it 404s. I'm aware there was some friction between Anthropic and OpenCode, but, is there a longer term socio-technical fix here?

    I'm pretty sure Dax is a fan of Claude models so I'm wondering, how is the OpenCode team accessing them. I'm guessing they don't go through a Claude subscription, or else we might have seen this fixed in the project itself, because surely this issue would be burning them at every step of the way. What are other users using to access their Claude subscriptions?

    Now you can add "plugin": ["@ex-machina/opencode-anthropic-auth"] and it will stop rewriting your directories. Go get em tiger!

    I'm going to give this a try. I haven't used any plugins yet, but I'm sure my agent will help me, if it doesn't get confused by rewriting "opencode" to "claude" along the way. 🙃

    Thanks, again!

  10. gotgenes commented on Feb 27, 2026

    @gotgenes
    gotgenes
    on Feb 27, 2026

    Thanks @eXamadeus — the @ex-machina/opencode-anthropic-auth plugin fixed it.

    Important

    Edit (2026-03-03): My original instructions were wrong — you don't need a package.json or manual install. OpenCode auto-installs npm plugins at startup. Corrected steps below.

    Corrected instructions

    1. Add the plugin to ~/.config/opencode/opencode.json:

    {
  "plugin": ["@ex-machina/opencode-anthropic-auth"]
}

    Note: the key is "plugin", not "plugins".

    2. Restart OpenCode and re-authenticate (if using Claude Pro/Max OAuth).

    That's it — two steps. OpenCode runs bun install at startup and caches the plugin in ~/.cache/opencode/node_modules/. No package.json, npm install, or bun install needed. See the plugin docs.

    If you followed my old (wrong) instructions

    You may have a stale unscoped opencode-anthropic-auth in the cache that still does the rewrite. To clean up:

    # Remove the unnecessary package.json and node_modules from the config dir
rm -rf ~/.config/opencode/package.json ~/.config/opencode/package-lock.json \
       ~/.config/opencode/bun.lock ~/.config/opencode/node_modules

# Clear the plugin cache so OpenCode rebuilds it cleanly
rm -rf ~/.cache/opencode/node_modules ~/.cache/opencode/bun.lock

# Restart OpenCode — it will auto-install plugins from your opencode.json
    Original (incorrect) instructions for reference

    1. Add the plugin dependency to ~/.config/opencode/package.json: ← unnecessary

    {
  "dependencies": {
    "@ex-machina/opencode-anthropic-auth": "latest",
    "@opencode-ai/plugin": "1.2.15"
  }
}

    2. Install it: ← unnecessary

    npm install    # in ~/.config/opencode/

    3. Configure OpenCode to use it in ~/.config/opencode/opencode.json: ← this was the only step that mattered

    4. Restart OpenCode and re-authenticate (if using Claude Pro/Max OAuth).

    Background: The old built-in plugin (opencode-anthropic-auth v0.0.13 in ~/.cache/opencode/node_modules/) does a global .replace(/opencode/gi, "Claude") on all system prompt text blocks before sending them to the API. The @ex-machina scoped version removes that block. Paths, AGENTS.md content, and directory names all come through intact.

  11. attkri commented on Mar 5, 2026

    @attkri
    attkri
    on Mar 5, 2026

    Reproducing this with Anthropic Subscription (OAuth). When switching from a non-Anthropic model to Opus or Sonnet directly, the compatibility layer activates and starts treating .opencode/ paths as the Claude Code directory — including writing files there. This causes the two folder structures to diverge and get increasingly out of sync the longer you work. The core issue is that the Claude Code compatibility shim should never silently redirect or transform user-controlled directory paths.

  12. gotgenes commented on Mar 6, 2026

    @gotgenes
    gotgenes
    on Mar 6, 2026

    This post by @thdxr reinforces my suspicion this hasn't gotten fixed in core because the team no longer dogfoods Anthropic. I do recommend the plugin by @eXamadeus to fix this on your install if you hit it, as stated in my earlier comment.

  13. eXamadeus commented on Mar 6, 2026

    @eXamadeus
    eXamadeus
    on Mar 6, 2026
    Contributor

    @gotgenes thanks for writing up better instructions than I provided!

    To all reading still having this issue, the simple solution to this is well explained in @gotgenes's comment above.

  14. rekram1-node commented on Mar 16, 2026

    @rekram1-node
    rekram1-node
    on Mar 16, 2026
    Collaborator

    We do not maintain that plugin anymore and will not make any edits to it

  15. rekram1-node
    closed this as not plannedon Mar 16, 2026

  16. eXamadeus commented on Mar 25, 2026

    @eXamadeus
    eXamadeus
    on Mar 25, 2026
    Contributor

    We do not maintain that plugin anymore and will not make any edits to it

    Yeah, that makes sense from a legal perspective. I have taken your original, forked it and made it my own.

    Converted it to TypeScript, updated it for new auth flows, etc. @rekram1-node would you mind if I opened a PR to add it to the plugins list in the docs?

    I know it's an active subject of discussion, so I feel like I should ask before I do it.

  17. rekram1-node commented on Mar 25, 2026

    @rekram1-node
    rekram1-node
    on Mar 25, 2026
    Collaborator

    No we cannot merge it, that was part of their demands too, no endorsing of community workarounds

  18. eXamadeus commented on Mar 26, 2026

    @eXamadeus
    eXamadeus
    on Mar 26, 2026
    Contributor

    @rekram1-node thanks that makes sense! Appreciate the insight.

  19. gotgenes
    added a commit that references this issue on Oct 14, 2026

    Rewrite agent instructions to survive Anthropic server-side path rewr…

    ae9918d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions