Repository navigation
OpenCode with Anthropic fails through Connect configured client #8288
Description
Client or integration
Other
Provider or upstream service
Anthropic OAuth, using an Anthropic subscription. Model tested: claude-opus-5-5.
OpenCodex version
OpenCodex 2.98.0 and OpenCode 2.2.5.
Endpoint or capability
OpenCode configuration generated by Connect.
Current behaviour
OpenCode requests through OpenCodex fail with HTTP 400. Codex requests through the same Anthropic account and model have succeeded.
I opened PR #8194 to address the difference in instruction placement. That PR remains open.
Expected behaviour
I want to use Anthropic through OpenCode and OpenCodex, as I already do through Codex.
Equivalent instruction content should follow a consistent translation path. If this use has an intentional limitation, please clarify what OpenCodex supports.
Minimal redacted request or reproduction
1. Configure an Anthropic OAuth account in OpenCodex.
2. Use the dashboard's Connect feature to configure OpenCode.
3. Start an OpenCode session and select opencodex/anthropic/claude-opus-5-5.
4. Send a prompt.
5. Observe the Anthropic rejection below.Actual response or error
HTTP 400 invalid_request_error
Third-party apps now draw from your extra usage, not your plan limits.
Add more at claude.ai/settings/usage and keep going.Upstream documentation
No documentation links supplied. This report is based on the Connect reproduction above.
Suggested mapping or implementation notes
My current view is that two things need attention:
- Connect should configure OpenCode V2 to use Responses. Export, launcher injection and managed refresh should generate the same configuration.
- Anthropic translation should account for the different ways clients supply instructions.
The instruction difference is reproducible offline:
{
"instructions": "The agent instructions"
}currently enters the translated system prompt, whereas:
{
"input": [
{
"role": "developer",
"content": "The agent instructions"
}
]
}follows the existing developer-message mapping, which places that content in Anthropic user messages.
Additional context and attachments
No response
Checks
- I searched existing provider and compatibility issues.
- The request and response were redacted.
- The expected behaviour is based on an upstream specification or a concrete client requirement.
Activity
coderabbitai commentedon Nov 7, 2026
🔗 Related PRs
#8194 - fix(anthropic): normalize caller instructions in translated OAuth requests [open]
#7374 - fix(combo): stop the prompt-cache usage leak — replay native Messages on Anthropic children [open]
📝 Issue Planner
Check the box below or use the
@coderabbitai plancommand to generate an implementation plan and prompts that you can use with your favorite coding assistant.🧪 Issue enrichment is currently in open beta.
To disable automatic issue enrichment, add the following to your
.coderabbit.yaml:💬 Have feedback or questions? Drop into our discord!
[-]OpenCode with Anthropic fails through Connect. What is the supported fix?[/-][+]OpenCode with Anthropic fails through Connect configured client[/+]Ingwannu commentedon Nov 7, 2026
Thanks. Two separate points on
dev(aaa3c20f3f):@ai-sdk/openai-compatible, or@opencode/ai/providers/openai-compatiblefor V2;src/clients/config-export.ts:186-197). OpenCode requests therefore enter through/v1/chat/completionsrather than/v1/responses. Moving Connect to Responses would change export, launcher injection and managed refresh for every OpenCode user, not only Anthropic routes. It needs its own scoped change and should not be bundled with the Anthropic fix.The instruction-placement change is under review in #8194. The owner has open concerns there about demoting the caller's system prompt to a user turn. Please keep the discussion of that approach on the PR. This issue stays open as the tracking item.
colthreepv commentedon Nov 7, 2026
"Moving Connect to Responses would change export, launcher injection and managed refresh for every OpenCode user, not only Anthropic routes" - yes, what's the problem?
This is an issue and not a PR, because I am not sure what's the intention of the maintainers, if OpenCode is actively supported, I think a migration to Responses is only about when, not if.
(2) 👀 I am not sure if I need to be more direct about this, we all know what this means
Ingwannu commentedon Nov 8, 2026
On the two new points:
src/clients/config-export.ts:187-197). Moving OpenCode to Responses would change the export, launcher injection and managed refresh for every OpenCode user, not only Anthropic routes. We do not have a committed timeline. The timing is a maintainer scope decision and needs its own tracked change.docs-site/src/content/docs/guides/opencode.md), so it is not an unsupported client. Whether its wire moves to Responses is still undecided, and we are not committing to a date here.Nothing else is new. The HTTP 400 text is Anthropic's subscription policy message, not a malformed request. The instruction-placement question stays on #8194, a draft where the owner's concerns are recorded. This issue stays open as the tracking item.