[apucacao]

What

The OpenCode handler now honors config["tools"] and tool_handlers, matching the contract every other handler follows. Previously _stream_impl did del tool_handlers and never read config["tools"], so the AI Config's tool catalog did nothing and every caller, including a judge, silently inherited whatever opencode.json already configured.

This is a behavior change for current callers: a variation with no tools, including every judge, now gets a model with no tools. The ! in the title is that break. The package is still 0.x, so release-please treats it as a minor.

How

• Offered set. The intersection of config["tools"] and the keys present in tool_handlers. A NativeTool is allowed by its provider tool name. A plain callable is served from a per-call loopback MCP bridge registered with POST /mcp. HTTP 200 is not enough: the body is the status map, and registration raises unless response.json()[name]["status"] is "connected".
• Bridge transport. The bridge keeps its GET open as a live text/event-stream instead of answering 405. OpenCode's MCP client (confirmed live against the opencode 1.18.4 linux-x64 binary) opens that GET right after initialize and marks the server connection "failed" on anything but a live stream, never sending tools/list. The spec allows 405 there; this client does not treat it as optional.
• Permission. The session ruleset always starts with deny *, then allows only the offered permissions. write and apply_patch are not their own permissions. OpenCode remaps both onto edit, so OpenCodeWrite and OpenCodeApplyPatch are the same grant as OpenCodeEdit, and the ruleset sends edit once. An empty offered set still denies everything. skill is denied unless it is offered.
• Spans. One chat per assistant message, one execute_tool per tool call, named after the AI Config key. A second completed message.updated for an id already recorded does not open another chat span. A consumer who stops reading marks launchdarkly.stream.abandoned. A CancelledError marks launchdarkly.run.cancelled instead.
• Sentinels. OpenCodeBash, OpenCodeRead, OpenCodeEdit, OpenCodeWrite, OpenCodeGlob, OpenCodeGrep, OpenCodeTask, OpenCodeSkill, OpenCodeTodoWrite, OpenCodeWebFetch, OpenCodeWebSearch, OpenCodeApplyPatch. There is no OpenCodeList.
• Client version. packages/client stays at 0.4.0; the earlier hand-bump to 0.4.1 is reverted so it does not fight release PR chore: release main #206 and $ld:ai:sdk:info does not report a version that was never published. launchdarkly-ai-opencode-agents still depends on launchdarkly-ai-server>=0.4.1, so a git pin of this SHA is not installable by a strict resolver until the client is actually released.

Live OpenCode 1.18.4

The opencode 1.18.4 linux-x64 binary runs here. A handler call with one plain callable, get_weather, against that binary now completes: the model called the bridged tool (CALLED [{'city': 'Oslo'}]), and the final answer is "The weather in Oslo is sunny." The earlier run failed with POST /mcp reporting {"status": "failed", "error": "SSE error: Non-200 status code (405)"} because the bridge answered its GET with a bare 405; OpenCode's client treats that as a dead connection and never sends tools/list. Traced live with a logging stand-in server: OpenCode sends POST initialize, POST notifications/initialized, then GET with Accept: text/event-stream — and only sends POST tools/list once that GET comes back as a live stream. The bridge now opens that stream (200, Content-Type: text/event-stream, an immediate : connected comment, then periodic keepalives) and holds it until stop().

Verification

uv run pytest packages/opencode-agents tests/test_cross_handler_parity.py -q
# 223 passed, 17 skipped
uv run mypy packages/opencode-agents/src
# Success: no issues found in 8 source files
uv run python scripts/api_report.py --check
# 15 API reports are current

test_tool_bridge.py::test_get_opens_a_live_sse_stream_not_405 reads a live chunk from the GET (not just the status line) and would have caught the 405 regression.

  

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Heads up for review: while wiring observability's Vega runtime to this commit (git pin, packages/client + packages/opencode-agents), I hit a pre-existing, unrelated version-floor conflict that blocks any Poetry- or pip-strict-resolver-based git pin to current main:

• packages/opencode-agents/pyproject.toml requires launchdarkly-ai-server>=0.4.1 (from fix!: pass AI Config model parameters through to every provider handler #107, already merged to main before this PR branched).
• packages/client/pyproject.toml's own version is still 0.4.0 (its last actual release) — that floor was raised ahead of an actual client release.

So poetry lock / pip's resolver refuses to install launchdarkly-ai-server @ git+...#subdirectory=packages/client alongside launchdarkly-ai-opencode-agents @ git+...#subdirectory=packages/opencode-agents from the same commit, since the declared floor (>=0.4.1) is never satisfied by the resolved version string (0.4.0) — even though the actual code is obviously compatible (same commit). I worked around it locally for testing with pip install --no-deps, and documented the real blocker in launchdarkly/observability#2693 (which depends on this PR), but I did not touch packages/client's version or the release-please manifest here — that's a release-versioning call for this repo's own maintainers, out of scope for what I was asked to do.

This will affect any consumer trying to git-pin main (or this branch) with a normal resolver until launchdarkly-ai-server actually releases ≥0.4.1.

[cursor]

Follow-up on the install failure: 569d3a1 lowers this package's requirement from launchdarkly-ai-server>=0.4.1 to >=0.4.0, which is the version packages/client still declares on this commit. A git pin of both packages from this SHA now resolves. No client version bump and no PyPI release. Vega's lock is regenerated against this commit in launchdarkly/observability#2693.

[jeffdupont]

The allow-list does not do what it says for edit-family tools: OpenCodeEdit also grants write and apply_patch, and OpenCodeWrite on its own grants nothing. The new dependency floor also lets PyPI install a client version this code cannot import.

PR title

This changes behaviour for current users. Today a call with no tool_handlers (including every judge) gets the tools in opencode.json. After this PR it gets none, because the session ruleset always denies *. Anyone who relies on host-configured tools loses them without warning. Since the package is 0.x, please make the title feat(opencode-agents)!: ... so release-please flags the break.

Spec (launchdarkly/ai-sdks-monorepo TESTING.md)

The handler is Python-only, so JS needs nothing. The spec still has nothing on this contract: the offered set as the intersection, deny-all for an empty set and for judges, and the OpenCode* sentinels. Other handlers' tool rules are written there, for example the Claude sentinels at TESTING.md:2792. Please add a short OpenCode section in the monorepo alongside this PR.

[jeffdupont]

e879883 covers everything from my first pass, and I've replied on each thread. Still needed before I approve:

1. Drop 928b977. Hand-bumping packages/client to 0.4.1 (pyproject.toml:3, __init__.py:6) conflicts with release PR #206 and mislabels $ld:ai:sdk:info for unreleased builds. It also moves uv.lock to revision 5, so please regenerate it with the repo's uv.
2. test_handler.py:1576 fails on macOS (/var vs /private/var). Compare Path(...).resolve() on both sides.
3. Tests the spec (ai-sdks-monorepo#89) asks for that aren't here yet:
   • offering only OpenCodeEdit, and only OpenCodeApplyPatch, each sends exactly [deny *, allow edit] (only the OpenCodeWrite case is covered, test_tool_contract.py:391);
   • a judge session is sent the deny-all ruleset (test_a_judge_opens_its_own_session, test_handler.py:1183, doesn't check permission);
   • skill is denied unless offered.
4. Could someone do one live run against opencode serve with a callable tool?

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit c0b5872. Configure here.}

[jeffdupont]

Thanks — f73110e, 767f500, c0b5872 and 594734e cover the version revert, the edit-grant/judge/skill tests, macOS paths, and both Bugbot findings. Two things left: uv.lock is still revision = 5 (main is 3), so please regenerate it with the repo's uv; and has anyone done the live run against opencode serve with a callable tool? Once those are in, I'll approve.

[apucacao]

Live run, against the OpenCode 1.18.4 linux-x64 binary, after the SSE fix in 8e84277:

A handler call with one plain callable, get_weather, completed. The model invoked it with {"city": "Oslo"}. The callable ran. The turn returned The weather in Oslo is sunny.

Before that fix, the same binary's POST /mcp returned {"status":"failed","error":"SSE error: Non-200 status code (405)"} because the bridge answered the client's GET with 405 and OpenCode never sent tools/list.