Repository navigation
"Unknown identifier query" in Code Mode with MCP tools #49115
Description
Bug Description
When calling MCP tools with a query parameter (e.g., search_nodes, search_memory_facts) from within OpenCode Code Mode, the JS interpreter throws:
Unknown identifier 'query'. (line 1, col 30)
Environment
- OpenCode version: 2.0.3
- MCP server: Graphiti MCP (running in Docker)
- MCP tools:
search_nodes,search_memory_facts(both havequeryas requiredstrparameter)
Steps to Reproduce
- Configure Graphiti MCP server in
opencode.json - Start OpenCode TUI/CLI with Code Mode
- Use a tool call referencing
search_nodesorsearch_memory_facts - JS interpreter fails with "Unknown identifier 'query'"
Expected Behavior
The query parameter should be available as a JS variable in the Code Mode sandbox.
Actual Behavior
JS interpreter throws Unknown identifier 'query'. (line 1, col 30) — the parameter is not declared in the JS scope before code execution.
Related Issues
- mcp: local tool calls return result: null, response text goes to Logs instead #48910 — Same version (2.0.3), same class of bug: MCP tool parameters not properly handled in Code Mode sandbox
- code mode: search() discovery function missing, execute reports Unknown tool search #48912 —
search()discovery function unregistered - codemode: tool discovery helper documented three ways; only bare search(input) works on 1.18.21 — README's 'never fails' claim is false #45521 —
search()documented 3 ways, only baresearch(input)works - code mode: catalog-listed MCP tools fail with Unknown tool unless invoked via execute #41389 — Catalog-listed MCP tools fail
Unknown tooloutsideexecute - MCP tool schemas are not sanitized for Anthropic: root-level anyOf/oneOf/allOf 400s, and tool.definition never sees MCP tools #46628 — MCP schemas bypass
tool.definitionhook
Root Cause Hypothesis
The Code Mode JS executor wraps LLM-generated code in an async function but doesn't declare MCP tool parameters (like query) as JS variables before execution. The LLM generates code referencing query but the variable doesn't exist in scope, causing the "Unknown identifier" error from acorn parser.
This is likely the same class of bug as #48910 — sandbox scope injection for MCP parameters is incomplete.
Activity
opencodejr commentedon Oct 28, 2026
Thanks for the report, @lehcode!
The
Unknown identifier '<name>'error comes from Code Mode's JavaScript interpreter. It's thrown when the program reads a variable that was never declared, the same as aReferenceErrorin normal JS. Code Mode doesn't put tool parameters in scope as variables. They're passed as an object argument, for example:So if the model wrote something like
search_nodes({ query })without declaringqueryfirst, this error is expected. If the code passedquerycorrectly and still failed, that would be a real bug in the interpreter. To tell which it is, could you share:executetool when the error happened. You can copy it from the expanded tool call in the TUI or from the session export. Column 30 of line 1 should point at thequeryin question.You can reply here with the details or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
I didn't find an existing report of this exact error. #48910, which you linked, is on the same version but is a different problem: MCP tool results come back as
null.rekram1-node commentedon Oct 29, 2026
This is the program referencing a variable it never declared: tool inputs are passed as an object, e.g.
await tools.graphiti.search_nodes({ query: "..." }), not as variables in scope. The error points at the line that usedquery, which is the expected behavior, so I'm closing this.opencodejr commentedon Oct 31, 2026
We haven't heard back, so I'm closing this issue for now as not planned.
We were waiting for the exact code the model passed to the
executetool, plus the provider and model. Without them we can't tell whether the model used an undeclaredqueryvariable (expected behaviour: tool parameters go in an object argument such assearch_nodes({ query: "..." })) or the interpreter mishandled valid code.If this still happens on a current v2 release, please comment here with that code and we can reopen. Thanks, @lehcode!