fix(agents): include browser in coding profile

[neeravmakwana]

Summary

• Problem: sessions using tools.profile: "coding" could still miss the browser tool even when browser support was configured and auto-enabled.
• Why it matters: browser-enabled coding sessions lost an expected tool surface, which made the browser integration look broken.
• What changed: added browser to the coding profile allowlist and added focused regression coverage for the coding-profile + browser-configured path.
• What did NOT change (scope boundary): browser plugin loading, browser service startup, and explicit plugin/tool disable behavior.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Browser enabled and running, but browser tool is missing from agent tool list #58628
• Related [Bug]: Browser enabled and running, but browser tool is missing from agent tool list #58628
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: browser config already auto-enabled the bundled browser plugin, but the coding tool profile still omitted browser, so profile filtering removed it from the effective tool list.
• Missing detection / guardrail: there was no regression test covering a browser-configured session running with tools.profile: "coding".
• Prior context (git blame, prior PR, issue, or refactor if known): issue [Bug]: Browser enabled and running, but browser tool is missing from agent tool list #58628 reported the mismatch between healthy browser runtime status and the missing runtime tool.
• Why this regressed now: the browser tool sits behind the bundled plugin surface, but the coding profile definition did not include it when the effective tool list was filtered.
• If unknown, what was ruled out: plugin auto-enable and bundled browser plugin resolution were both verified separately and still worked.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/agents/openclaw-tools.browser-plugin.integration.test.ts
• Scenario the test should lock in: when browser is configured and the coding profile is active, the effective coding tools should still include browser.
• Why this is the smallest reliable guardrail: it exercises the real bundled browser plugin path plus the profile filtering path without requiring a full browser runtime.
• Existing test that already covers this (if any): src/agents/tool-catalog.test.ts now also asserts the coding profile includes browser.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• Browser-enabled sessions using the coding profile now keep the browser tool available.

Diagram (if applicable)

Before:
[browser configured] -> [coding profile filtering] -> [browser tool dropped]

After:
[browser configured] -> [coding profile filtering includes browser] -> [browser tool available]

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): Yes
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: this restores the intended browser tool exposure only for browser-configured coding sessions; explicit plugins.entries.browser.enabled = false, plugins.deny, and tool deny policies still block it.

Repro + Verification

Environment

• OS: macOS 15 / darwin 25.3.0
• Runtime/container: local repo checkout via pnpm
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): browser.enabled: true, browser.defaultProfile: "openclaw", tools.profile: "coding"

Steps

1. Configure browser support and set tools.profile to coding.
2. Build the effective coding tool list.
3. Check whether browser is present.

Expected

• browser is present in the effective coding tool list.

Actual

• browser was filtered out even though browser support was configured.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • Reproduced the missing browser tool with a coding-profile config before the fix.
  • Verified src/agents/tool-catalog.test.ts and src/agents/openclaw-tools.browser-plugin.integration.test.ts pass after the fix.
  • Verified pnpm build passes after the change.
• Edge cases checked:
  • Browser remains omitted when the bundled browser plugin is explicitly disabled.
  • Messaging profile behavior remains unchanged.
• What you did not verify:
  • A live browser roundtrip through a running OpenClaw browser service.
  • Full-repo pnpm check / pnpm test green state, because unrelated existing failures outside this change still block them.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk: broadening the coding profile could expose browser where maintainers did not intend it.
  • Mitigation: the change is limited to the declared coding profile; browser still requires the plugin/config path to be enabled, and explicit deny/disable settings still take precedence.

Additional Notes

• Broader repo verification is currently blocked by unrelated existing failures in extensions/diffs/src/language-hints.test.ts during pnpm check and src/config/schema.base.generated.test.ts during pnpm test.
• AI-assisted: yes.
• Testing degree: pnpm build, pnpm test -- src/agents/tool-catalog.test.ts src/agents/openclaw-tools.browser-plugin.integration.test.ts, plus direct local repro of the missing-tool behavior before the fix.

Made with Cursor

[greptile-apps]

Greptile Summary

This PR fixes a bug where the browser tool was dropped from effective tool lists for sessions that combined tools.profile: "coding" with a browser-configured environment. The root cause was that browser had an empty profiles array in tool-catalog.ts, so profile-based allowlist filtering silently removed it even after the bundled browser plugin had successfully loaded. The one-line fix (profiles: [] → profiles: ["coding"]) is correct and minimal.

Changes:

• src/agents/tool-catalog.ts — adds "coding" to the browser tool's profile list, restoring it to the effective coding tool allowlist.
• src/agents/tool-catalog.test.ts — extends the existing unit test to assert browser is present in the coding profile policy.
• src/agents/openclaw-tools.browser-plugin.integration.test.ts — adds a new integration scenario covering the createOpenClawCodingTools + browser.enabled: true + profile: "coding" path.

Minor style note: The new integration test uses createOpenClawCodingTools (from pi-tools.ts) inside a describe block named "createOpenClawTools browser plugin integration" that otherwise tests only createOpenClawTools (from openclaw-tools.ts). Moving the new test to its own block or an existing pi-tools test file would keep organisation cleaner, but this does not affect correctness.

Confidence Score: 5/5

• Safe to merge — the fix is a single-field, one-line change with appropriate unit and integration test coverage, and explicit deny/disable paths remain unaffected.
• The core change is minimal and clearly correct. All remaining findings are P2 style/organisation suggestions that do not affect runtime behaviour or test validity. No data loss, security, or correctness risks were identified.
• No files require special attention beyond the minor test-organisation note on openclaw-tools.browser-plugin.integration.test.ts.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: src/agents/openclaw-tools.browser-plugin.integration.test.ts
Line: 63-80

Comment:
**New test belongs in a different describe block**

The new test case calls `createOpenClawCodingTools` (from `pi-tools.ts`), while the enclosing `describe` block is named `"createOpenClawTools browser plugin integration"` and all other tests invoke `createOpenClawTools` (from `openclaw-tools.ts`). These are distinct functions from different modules, so the new test is semantically out of place here.

Moving it to a dedicated `describe` block (or to an existing `pi-tools` test file, e.g. `pi-tools.create-openclaw-coding-tools.*.test.ts`) would keep test organisation consistent and make the coverage easier to find during future triage.

This doesn't affect correctness — the test is otherwise well-structured — but it may confuse reviewers or tooling that expects a 1:1 between the describe name and the module under test.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "Agents: include browser in coding profil..." | Re-trigger Greptile}

[neeravmakwana]

Addressed the review feedback and pushed follow-up commit ff3c5821e7.

What changed:

• Moved the createOpenClawCodingTools(...) browser regression out of src/agents/openclaw-tools.browser-plugin.integration.test.ts.
• Added a dedicated src/agents/pi-tools.browser-plugin.integration.test.ts file for that coverage instead.
• Kept src/agents/openclaw-tools.browser-plugin.integration.test.ts focused on createOpenClawTools(...) only.

Why:

• This keeps the integration suites aligned with the module under test and makes the browser coding-profile regression easier to find during future triage.
• No production behavior changed in this follow-up; this is test organization only.

Verification rerun after the move:

• pnpm test -- src/agents/tool-catalog.test.ts src/agents/openclaw-tools.browser-plugin.integration.test.ts src/agents/pi-tools.browser-plugin.integration.test.ts

I also resolved the addressed review thread.