[Provider compatibility] Qoder adapter cannot use Codex-owned MCP/tool calls
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- typescript
Research direction
Locate the Qoder adapter that launches the CLI with --tools "" and --strict-mcp-config, then reproduce the /v1/responses request with a Codex-owned tool. Trace how tool_call, function_call_output, and continuation are handled; done means Qoder can request supplied tools while Codex retains approval, sandboxing, and execution across continuation turns.
Written by the indexing model from the issue text.
Description
Client or integration
Codex CLI
Provider or upstream service
Qoder
OpenCodex version
2.59.0 (134c92a01b120162f00c7275189cc47858720379)
Endpoint or capability
/v1/responses — tool calls / MCP tools
Current behaviour
The upstream Qoder adapter launches Qoder in a single-shot, tools-disabled mode.
Its argument list includes:
--tools ""
--strict-mcp-config
--max-turns 1
--no-session-persistence
Because tools are disabled, tools supplied by the Codex/Responses request are not exposed to Qoder. A request that requires a Codex-owned tool cannot enter the normal tool-call continuation flow through the Qoder adapter.
Expected behaviour
Qoder should be able to request tools supplied by Codex/OpenCodex while Codex remains responsible for approval, sandboxing, and actual tool execution.
The expected flow is:
Qoder requests tool
→ OpenCodex returns a tool_call
→ Codex executes the tool
→ function_call_output is sent back
→ Qoder continues
→ final response
Minimal redacted request or reproduction
- Configure Qoder as the provider for
/v1/responses. - Send a Responses request containing at least one function/MCP tool.
- Use a prompt that requires that tool.
- Observe that the upstream Qoder adapter starts the CLI with
--tools ""and--strict-mcp-config, so the supplied tool is unavailable to Qoder.
Actual response or error
There is no required HTTP error.
The failure is capability-level: the Qoder adapter disables tools, so a tool-required request cannot produce and complete the normal Codex-owned tool_call → function_call_output → continuation flow.
Upstream documentation
No public specification was found for Qoder's internal host/control protocol.
The OpenCodex 2.59.0 Qoder adapter itself documents and implements the current single-shot, tools-disabled behavior.
Suggested mapping or implementation notes
A local proof-of-concept can bridge Qoder tool intent back to Codex while keeping Codex as the actual tool executor, including multi-tool continuation.
That proof-of-concept is local work and is not being proposed here as the final architecture. This issue only tracks the base Qoder tool-compatibility gap.
Additional context and attachments
A separate architecture discussion can cover lifecycle and performance trade-offs after the base compatibility problem is established.
Checks
- I searched existing provider and compatibility issues.
- The request and response were redacted.
- The expected behaviour is based on a concrete client requirement.
- Dominant language
- TypeScript
- Stars
- 16.9k
- Forks
- 1.3k
- Avg merge
- 9h 39m
- Merged PRs (30d)
- 633
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from lidge-jun/opencodex
-
catalog enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
lidge-jun/opencodex#7704 · 1 comment ·
Maintainers usually reply within 1 day
-
bug streaming
Difficulty 4/5 3-5 days Newbie friendliness 35/100
lidge-jun/opencodex#7720 · 2 comments ·
Maintainers usually reply within 1 day
-
bug gui platform
Difficulty 4/5 3-5 days Newbie friendliness 45/100
lidge-jun/opencodex#7716 · 1 comment ·
Maintainers usually reply within 1 day
-
account-pool provider provider-compatibility
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
-
catalog enhancement
Difficulty 5/5 Over a week Newbie friendliness 30/100
lidge-jun/opencodex#7705 · 1 comment ·
Maintainers usually reply within 1 day
All issues in lidge-jun/opencodex
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
MoonshotAI/kimi-code#4398 ·
Maintainers usually reply within 1 day
-
Xiaomi Mimo语音识别服务异常Openpending triage
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
package-lock.json : les binaires natifs macOS et Linux de unrs-resolver ont disparu depuis #1823Openbug dependencies
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
AxaFrance/design-system#2064 ·
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 85/100