Skip to content

feat(mcp): disable Playwright MCP by default#77

Merged
UmarFarooq75 merged 1 commit into
devfrom
feat/disable-browser-mcp-default
May 7, 2026
Merged

feat(mcp): disable Playwright MCP by default#77
UmarFarooq75 merged 1 commit into
devfrom
feat/disable-browser-mcp-default

Conversation

@UmarFarooq75
Copy link
Copy Markdown
Collaborator

Summary

Flip Playwright MCP's default `enabled` from `true` to `false`. Browser tools become opt-in — neither the main agent nor the browser-pilot crew sees `browser_navigate`, `browser_click`, `browser_screenshot`, etc. until the user explicitly enables the Playwright server from the MCP settings UI.

Why

The main agent shouldn't reach for browser tools unprompted. The intent is:

  • Browser work → `use_crew("browser-pilot", ...)` deliberately
  • Main agent stays focused on orchestration

When the user enables Playwright via the UI, both the main agent and browser-pilot get the tools back simultaneously (current architecture is single shared MCP server, no per-crew scoping yet — that's a separate larger change tracked elsewhere).

Affected behaviour

  • Fresh installs: no browser tools by default. User clicks Enable in MCP settings → tools restored to both the main agent and browser-pilot.
  • Existing users: their `mcp.json` already has `enabled: true` from when they first installed; this PR doesn't migrate that. They keep browser tools unless they manually disable.

Test plan

  • `npx tsc --noEmit` clean
  • Fresh install: confirm Playwright doesn't show in the agent's tool list
  • Enable Playwright from MCP settings: confirm `browser_*` tools reappear, browser-pilot can run
  • Disable again: confirm both surfaces lose the tools

Browser tools are now opt-in. Until the user enables Playwright from
the MCP settings UI, neither the main agent nor the browser-pilot crew
sees browser_navigate/click/screenshot/etc. The intent is that browser
work routes through use_crew("browser-pilot", ...) deliberately rather
than the main agent reaching for browser tools unprompted.

When the user does enable it, both the main agent and browser-pilot
get the tools simultaneously — current architecture is single MCP
server, shared catalog. (Per-crew MCP scoping would be a separate
larger change.)
@UmarFarooq75 UmarFarooq75 merged commit 15ff9dc into dev May 7, 2026
@UmarFarooq75 UmarFarooq75 deleted the feat/disable-browser-mcp-default branch May 7, 2026 14:11
UmarFarooq75 added a commit that referenced this pull request May 7, 2026
## Summary
Promotes the installer + safety changes from \`dev\` to \`main\`.

What lands:

- **PR #78** \`feat(install): native installers (.pkg + .exe)\` — proper
macOS \`.pkg\` builder + Windows Inno Setup \`.exe\` with real icons.
Replaces the curl-pipe scripts as the recommended path for non-technical
users.
- **PR #77** \`feat(mcp): disable Playwright MCP by default\` — browser
tools become opt-in. Main agent and browser-pilot crew don't see
\`browser_*\` tools until the user enables Playwright in MCP settings.
- **PR #75** + follow-up fixes \`1cf856f\` and \`f61032a\` — the
original curl-pipe scripts plus the two patches I pushed during testing
(osascript GUI password prompt for non-TTY sudo; Unicode ellipses
replaced with ASCII so \`set -u\` doesn't choke).

After merge, the README's
\`raw.githubusercontent.com/.../main/scripts/install.sh\` URL resolves
and the legacy curl-pipe path keeps working alongside the new native
installers. Future cleanup (deleting the curl-pipe scripts since the
native installers are the recommended path) can be a follow-up commit.

## Test plan
- [ ] After merge, build the macOS \`.pkg\` from
\`installer/macos/build-pkg.sh\`, run on a clean Mac, confirm app
installs and dashboard opens
- [ ] Run \`installer/windows/Output/DaemoraSetup.exe\` on a clean
Windows box, confirm same
- [ ] Confirm browser tools are absent from main agent's tool list on a
fresh install (PR #77 default)
- [ ] Verify
\`https://raw.githubusercontent.com/CodeAndCanvasLabs/Daemora/main/scripts/install.sh\`
resolves
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.

1 participant