fix(opencode): pass input args to augment hook and allow tool search in subagents

[Chewji9875]

Summary

This PR resolves two issues affecting OpenCode integration:

1. Fix output?.args typo in OpenCode plugin adapter (src/cli/client_adapter.c):
   In OpenCode's plugin API for tool.execute.after(input, output), the arguments passed to the executed tool reside in input?.args, while output contains the result (output?.output). Passing output?.args passed undefined, causing hook-augment to receive an empty payload {"tool_input":{}} and silently failing to augment search results with graph context (Closes Generated OpenCode plugin passes output?.args to hook-augment, so augmentation never fires #1737).

2. Add tool_search and tool_search_regex permissions to OpenCode subagent profiles (src/cli/agent_profiles.c):
   When OpenCode subagents are generated with permission: "*": deny, they were granted read, grep, and glob alongside direct MCP tool permissions. In environments with deferred MCP tool loading (e.g. openstellar-tool-search), OpenCode needs tool_search or tool_search_regex to discover and unlock deferred tools. Adding these permissions enables subagents to unblock graph tools as intended.

Changes

• src/cli/client_adapter.c: Changed output?.args to input?.args in cbm_client_adapter_opencode.
• src/cli/agent_profiles.c: Updated CBM_GRAPH_DIALECT_OPENCODE subagent template to allow tool_search and tool_search_regex.
• tests/test_agent_clients.c: Added assertions verifying input?.args presence and output?.args absence.
• tests/test_agent_profiles.c: Added agent_profiles_opencode_allows_tool_search_and_subagent_permissions test.

Verification

• Ran ./scripts/test.sh --suites "agent_clients agent_profiles" — 49/49 tests passing.
• Verified C binary compilation via ./scripts/build.sh.

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thanks for this, and apologies that the only thing on the thread so far was the automated acknowledgement.

Three things stand between this and review. One of them is mine, not yours.

1. Mine — a conflict I caused. #1487 merged about an hour ago (1e3f2fd2), extending the OpenCode plugin across its context surfaces, and it touches the same file you do. Checked with git merge-tree against current main (20e86c02): the conflict is exactly one file, src/cli/client_adapter.c. agent_profiles.c and both test files auto-merge cleanly. Worth reading what #1487 changed there before you re-anchor — the two changes look complementary rather than overlapping, but you will want to confirm your one-line edit still lands where you intend.

2. Lint — two clang-format violations, both on one line:

src/cli/agent_profiles.c:553:24
src/cli/agent_profiles.c:553:96

make -f Makefile.cbm lint-format reproduces it. One caveat that catches people here: use the Homebrew LLVM clang-format — a standalone clang-format-20 reports spurious whole-file drift.

3. DCO — the commit needs a sign-off. It is a single commit (9bd1cdd6), so amending it with -s and force-pushing with lease covers it.

None of that is a comment on the change itself, which at +32/−1 across four files is exactly the shape that is pleasant to review — one claim, tests alongside it. It has not been read on the merits yet; the queue is deep and that part is on us. Clear those three and it goes into review properly.

[JCVIDev]

#1487 is the branch that landed on top of you here — it merged into the same file about an hour after you opened this and restructured the block your one-line edit sits in. Sorry for the re-anchor; here is what changed, so you do not have to read my diff to find out.

The good news is that the edit gets simpler, not harder. On current main the rewritten tool.execute.after block has exactly one args binding:

/* src/cli/client_adapter.c:318 */
"      const args = output?.args ?? {};\n"

and both consumers read from it — tool_input: args at 325 for the grep/glob lookup, and args.filePath ?? args.file_path ?? args.path at 329 for the post-read coverage note that #1487 added. So your change is still a single line in a single place:

"      const args = input?.args ?? {};\n"

It now fixes two surfaces instead of one. #1487 extended the defect you found to the new post-read path without noticing it, so your PR is worth more against post-merge main than it was when you filed it.

Corroborating #1737 from a different angle, in case it is useful for the review: the arguments are on input at all five tool.execute.after trigger sites inside the OpenCode binary (v1.18.25) — native tools, the three MCP resource tools, generic MCP tools, and the subtask path — not just in the published typings.

yield* i.trigger("tool.execute.after",
  { tool: u.id, sessionID: H.sessionID, callID: H.callID, args: b },
  V);

output there is the tool result, { title, output, metadata, attachments? }, with no args field on any path.

Happy to help with the rebase if it would save you time.