fix(tool): route website tasks to opencli adapters before the browser - #1280
Conversation
The bundled OpenCLI site adapters (162 sites, 1050 commands) are deferred tools, exposed only as a one-line `opencli` card inside tool_info, so the agent almost never discovered them. Worse, the resident prompt actively routed every website task to the competing `browser` group: the "# Browsing and operating websites" section and the shell.txt redirect both pointed only at the browser tools. Same failure class as the earlier automate misroute (ae981f0) — a capable tool losing to a more familiar default because nothing in the resident prompt routes to it. Changes (copy + contract tests only; no execute() change): - pawwork.txt browsing section: adapter-first routing keyed on action intents (check account, search, book, order, post, pull structured data), not site names (the manifest is dynamic). Explicit fallback to the browser group on no match or adapter error, capped at one retry. A permission-denial stop so a declined OpenCLI/browser permission is never worked around with another tool. webfetch and the curl/wget guard kept. - shell.txt redirect: check opencli_search for a bundled adapter first, then fall back to the browser tools. - Contract tests pin the new ordering, fallback, one-retry cap, and permission-denial stop across both resident surfaces (registry.test.ts), plus a system-prompt anchor (system.test.ts). The old browser-only routing assertion is replaced. Verification: - bun test test/tool/registry.test.ts test/session/system.test.ts test/tool/shell-prompt.test.ts test/tool/opencli-tools.test.ts — 73 pass. - bun run typecheck (packages/opencode) — clean. Follow-up (out of scope): navigate-time discovery — surface a matching adapter from the browser tool result when navigating to a domain that has one, so the model is pulled back even if it ignored the resident routing.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThis PR shifts website-browsing routing from browser-first to adapter-first: the system now searches for site-specific OpenCLI adapters before falling back to browser tools, includes a stop rule preventing tool-switching after permission denial, and updates corresponding test assertions. ChangesAdapter-First Browsing Routing
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
ESLint install failed. For unrecoverable errors, disable the tool in CodeRabbit configuration. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Code Review
This pull request updates the web browsing and operation guidelines to prioritize purpose-built site adapters via the opencli tool group (opencli_search and opencli_run) before falling back to the embedded browser tool group. It also introduces rules for handling permission denials and limiting adapter retries, and updates the corresponding shell usage notes and tests. Feedback was provided to clarify an ambiguous reference to "these tools" in the prompt guidelines to prevent models from mistakenly using forbidden tools like curl or wget.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
Codex review (P1): the `browser` group card in tool-info.ts is a resident surface shown every turn in tool_info's listing, and it still told the model to "use for any task that needs to browse, read, or operate a website" — directly contradicting the new adapter-first routing and re-creating the same misroute the PR fixes. Reword the browser card to fallback semantics (general browsing, visual checks, sites without an adapter; check the opencli group first) and the opencli card to prefer adapters over the browser when one matches. Codex review (P2): harden the browsing routing contract test — assert the shell redirect can't drift back to browser-first, the adapter-first ordering (opencli_search before the browser fallback), and that the browser group card no longer carries the conflicting "any website task" steer. Verification: - bun test test/tool/registry.test.ts test/session/system.test.ts test/tool/tool-info.test.ts test/tool/opencli-tools.test.ts test/tool/shell-prompt.test.ts — 104 pass. - bun run typecheck (packages/opencode) — clean.
Codex review round (xhigh, web search on)Verdict: prompt-only is the right altitude — no need for the heavier navigate-time interception now. But codex caught a missed resident surface and a test gap. Both fixed in
Re-verified after the fix: Confirmed out-of-scope (codex agreed): navigate-time discovery as the structural backstop — see the Follow-up section in the PR body. |
Three P3 copy-ambiguity fixes from code review (copy + contract tests only): - pawwork.txt: "without trying these tools first" had an unclear referent (a weak model could read it as curl/wget or webfetch) — name the tools: "trying the `opencli` or `browser` tool groups first". - pawwork.txt: drop the ambiguous "blocked" from the adapter-failure fallback (it could be conflated with a user permission denial) and make the permission-denial stop an explicit contrast: "is not an adapter failure to route around". - shell.txt: the redirect triggered on "a specific site" (broader than the system prompt's action-intent routing); re-key it on acting on a site (sign in, search, book, post, pull data) and carve out one-shot reads to webfetch so it stays in step. Contract test updated to pin the new action-intent trigger, the permission-vs-adapter-failure distinction, and the named "try first" pointer, with regression guards against the old visit-based and ambiguous phrasings. Verification: - bun test test/tool/registry.test.ts test/session/system.test.ts test/tool/tool-info.test.ts test/tool/opencli-tools.test.ts test/tool/shell-prompt.test.ts — 104 pass. - bun run typecheck (packages/opencode) — clean.
Code review round 2 — P3 copy fixes (
|
Summary
Add resident-prompt routing so the agent reaches for the bundled OpenCLI site adapters before manually driving the embedded browser. Adapter-first for specific-site tasks, with an explicit fallback to the browser group.
pawwork.txt"# Browsing and operating websites": adapter-first routing keyed on action intents (check account, search, book, order, post, pull structured data), not site names (the manifest is dynamic — 162 sites / 1050 commands). Explicit fallback to thebrowsergroup on no match or adapter error, capped at one retry. A permission-denial stop so a declined OpenCLI/browser permission is never worked around with another tool.webfetchand the curl/wget guard kept.shell.txtredirect: checkopencli_searchfor a bundled adapter first, then fall back to the browser tools.Copy + contract tests only. No
execute()/ runtime change.Why
The OpenCLI adapters shipped in #(521b01e) as deferred tools — exposed only as a one-line
openclicard insidetool_info— so the agent almost never discovered them. Worse, the resident prompt actively routed every website task to the competingbrowsergroup (the browsing section and the shell redirect both pointed only at the browser tools). So "check my 12306 account" → read browsing section → activate browser → hand-drive the page → never find the12306/meadapter.Same failure class as the earlier automate misroute (
ae981f021e): a capable tool losing to a more familiar default because nothing in the resident prompt routes to it. That fix added a pawwork.txt routing section + shell.txt redirect + contract tests; this mirrors it for opencli.This direction and final shape were pressure-tested by an independent fresh-eye review and a Codex consult — both converged on: prompt-only is the right altitude (don't un-defer the tools), key on action intents not site names, two tiers not three, and pin the rule with contract tests.
Related Issue
None.
Human Review Status
Pending
Review Focus
pawwork.txt— is the adapter→browser fallback order and the permission-denial stop unambiguous to a weak model?Risk Notes
Resident system-prompt behavior change: the agent will now spend one
opencli_searchturn on specific-site tasks before falling back to the browser. Mitigated by keying on action intents so pure one-page reads still go towebfetch. No runtime, permission, or packaging surface touched. UI checklist item left unticked: no visible UI or copy-in-app changed (this is the agent system prompt, not user-facing copy).How To Verify
Screenshots or Recordings
N/A — no visible UI change.
Checklist
bug.harness(prompts + tool descriptions).P2.Pending.dev, and my PR title and commit messages use Conventional Commits in English.Follow-up (out of scope)
Navigate-time discovery — when the browser navigates to a domain that has a bundled adapter, surface the matching adapter from the browser tool result so the model is pulled back even if it ignored the resident routing. Prompt routing is best-effort (the model can ignore it); a navigate-time hook is the structural backstop. Deferred here because it touches the tool execution path and needs its own tests.
Summary by CodeRabbit