Skip to content

plugin: add harness/call-tool so plugins can invoke dirge's tools - #1 - #813

Merged
yogthos merged 1 commit into
dirge-code:mainfrom
wayniacal:feat/harness-call-tool
Aug 24, 2026
Merged

plugin: add harness/call-tool so plugins can invoke dirge's tools - #1#813
yogthos merged 1 commit into
dirge-code:mainfrom
wayniacal:feat/harness-call-tool

Conversation

@wayniacal

Copy link
Copy Markdown
Contributor

Plugins could register tools and intercept them, but not call one. A plugin that wanted a tool's output had to reimplement it — and therefore reimplement its permission checks — and could never reach MCP or semantic tools at all.

Adds three Janet functions, modelled on the LSP bridge:

(harness/tools?) bridge live?
(harness/list-tools) JSON of {name, description, parameters}
(harness/call-tool name args) -> @{:ok bool :output string}

src/plugin/tool_bridge.rs holds the policy and the tokio responder; the FFI sits in worker.rs with the other C functions. The registry is republished on every agent build rather than captured once, since the agent is rebuilt at run boundaries and MCP tools attach late.

Permission checks are unaffected: check_perm* runs inside each tool, so dispatching straight to LoopTool::execute keeps the gate. Verified — under --restrictive a plugin's bash and write return "Permission denied by user" and nothing runs.

Two calls are refused rather than attempted, both of which would hang: plugin-registered tools (their handlers need the Janet worker, which is blocked awaiting the reply) and task (subagents run isolated from plugin hooks). Hooks do not fire for bridged calls, for the same re-entrancy reason maki's Emit::Silent exists.

Two deadlocks found by running it, not by reading it:

  • The bridge must not touch the PluginManager lock. The hook dispatcher holds it across the Janet call and it is not reentrant, so asking for it from a harness C function — or from the responder the worker is blocked on — hangs the agent. Plugin tool names are now cached from the build path instead.

  • Headless --print dispatched on-prompt inline on the runtime thread, and the runtime is flavor = "current_thread". Any harness bridge that waits on a reply from the runtime could never be answered. Now dispatched via spawn_blocking, matching the tool hooks and the TUI path. This also fixes harness/lsp and harness/confirm from on-prompt under -p.

Adds docs/plugins.md coverage, plugins/call_tool_example.janet, refusal and flatten unit tests, and Janet-level tests that the symbols exist and degrade to nil when the bridge is unwired.

Plugins could register tools and intercept them, but not call one. A plugin
that wanted a tool's output had to reimplement it — and therefore reimplement
its permission checks — and could never reach MCP or semantic tools at all.

Adds three Janet functions, modelled on the LSP bridge:

  (harness/tools?)                 bridge live?
  (harness/list-tools)             JSON of {name, description, parameters}
  (harness/call-tool name args)    -> @{:ok bool :output string}

src/plugin/tool_bridge.rs holds the policy and the tokio responder; the FFI
sits in worker.rs with the other C functions. The registry is republished on
every agent build rather than captured once, since the agent is rebuilt at run
boundaries and MCP tools attach late.

Permission checks are unaffected: check_perm* runs inside each tool, so
dispatching straight to LoopTool::execute keeps the gate. Verified — under
--restrictive a plugin's bash and write return "Permission denied by user" and
nothing runs.

Two calls are refused rather than attempted, both of which would hang:
plugin-registered tools (their handlers need the Janet worker, which is
blocked awaiting the reply) and `task` (subagents run isolated from plugin
hooks). Hooks do not fire for bridged calls, for the same re-entrancy reason
maki's Emit::Silent exists.

Two deadlocks found by running it, not by reading it:

- The bridge must not touch the PluginManager lock. The hook dispatcher holds
  it across the Janet call and it is not reentrant, so asking for it from a
  harness C function — or from the responder the worker is blocked on — hangs
  the agent. Plugin tool names are now cached from the build path instead.

- Headless --print dispatched on-prompt inline on the runtime thread, and the
  runtime is flavor = "current_thread". Any harness bridge that waits on a
  reply from the runtime could never be answered. Now dispatched via
  spawn_blocking, matching the tool hooks and the TUI path. This also fixes
  harness/lsp and harness/confirm from on-prompt under -p.

Adds docs/plugins.md coverage, plugins/call_tool_example.janet, refusal and
flatten unit tests, and Janet-level tests that the symbols exist and degrade
to nil when the bridge is unwired.
@wayniacal
wayniacal marked this pull request as ready for review August 24, 2026 10:54
@yogthos
yogthos merged commit 80d30e1 into dirge-code:main Aug 24, 2026
15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants