You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "Astro-Han (via GitHub)" <gi...@apache.org> on 2026/09/23 16:12:53 UTC
[PR] feat(mcp): connect the user's signed-in Chrome through opencli-mcp [maka]
Astro-Han opened a new pull request, #5638:
URL: https://github.com/apache/maka/pull/5638
## Summary
Maka's built-in browser tools drive the conversation's embedded browser, which has none of the user's logins. This PR adds the other half: an MCP connection to the user's own signed-in Chrome through [opencli-mcp](https://github.com/jackwener/opencli-mcp), bundled with Maka and set up from the MCP page.
**Flow.** 扩展 → MCP → 推荐 → **Chrome +**. The click stores a stdio connection and opens the Chrome Web Store page for the extension in Chrome. The row shows **等待 Chrome** (attention) and the detail keeps a **连接 Chrome** action until the extension reaches the host. The page polls the host every 2 s while that is pending, so nothing needs refreshing.
**Why one store click remains.** Chrome installs consumer extensions only from the Web Store; silent install exists only as enterprise policy. Everything else `opencli-mcp setup` does now runs inside Maka:
- **No Node install.** Maka runs opencli-mcp on its own Electron binary with `ELECTRON_RUN_AS_NODE`. Two launchers under `userData/opencli-mcp/` are rewritten on every start, and they are the only paths stored in `mcp.json` and in Chrome's host manifest. The executable path itself moves on every AppImage launch.
- **Maka writes the Native Messaging manifest itself** instead of calling opencli-mcp's `registerHost`. That function's launcher runs `process.execPath` without `ELECTRON_RUN_AS_NODE`, which under Electron would start a Maka window. The directory list, profile detection and identifiers are imported from the package, not copied. A manifest that points at another live install (for example a global `opencli-mcp setup`) is left alone; the stdio server reaches whichever host Chrome starts. Registration writes into Chrome's directories only when the user clicks.
- **Chrome status comes from the host's `/health`, not from the MCP connection.** Without the extension, the server still starts in its embedded runtime and lists all 16 tools. Showing that as "connected" would hide the missing step until a `tab_*` call fails.
The built-in `browser_*` tools are unchanged. The two cover different scenarios: the embedded browser is visible inside Maka and has no logins; this connection drives the user's own Chrome.
**Packaging.** opencli-mcp 0.0.12 is pinned exactly and has no type declarations, so the few imported modules are declared in `opencli-mcp.d.ts`. It ships its adapter SDK inside itself and links it with `file:`, which npm locks without a version. The notice generator now reads such bundled packages from their installed manifest. The SDK declares MIT but has no LICENSE file, so it gets an exact-version copyright override.
## Verification
- `opencli-chrome.test.ts`: the POSIX launchers actually run an entry in Node mode, including a path that contains a quote (`stdio` and `host --native`, with Chrome's appended origin ignored); Windows `.cmd` content; manifest targeting (Chrome always, other browsers only when their profile exists, a stale manifest overwritten, another live install kept).
- `module-hub-mcp-controller.test.ts`: a configured Chrome server is polled until the extension connects, and polling then stops. `mcp-preload-scope.test.ts` covers the two new channels.
- Stories: `ExtensionsMcpChrome` (the click adds the server, starts connecting once, leaves 推荐) and `ExtensionsMcpChromeWaiting` (the row shows 等待 Chrome and counts as needing attention, not "16 个工具"). Storybook smoke passes: 409 stories, 443 theme renders.
- Packaged app: `electron-builder --mac dir`, then `ELECTRON_RUN_AS_NODE=1 Maka.app/Contents/MacOS/Maka app.asar/node_modules/opencli-mcp/dist/src/main.js stdio` initializes and runs `sites_search` (adapters load from the asar).
- Dev app with an isolated profile, driven over CDP: the launchers are written at startup; adding the server through `window.maka.mcp.add` connects with 16 tools and `chromeStatus().connected === false`.
- `typecheck`, `typecheck:stories`, `format`, `lint`, `check:third-party-notices`, `audit-shipped-dependencies`, `windows:inventory`.
**Not run:** Chrome → `opencli-mcp-host` → extension with the real Web Store extension installed; that needs a user to click Add to Chrome. Windows and Linux were not run locally. E2E is left to CI.
## AI use
- [ ] No generative tool made a substantive contribution
- [x] Generative tooling made a substantive contribution
Tool(s) and scope: Claude Code: investigation, implementation, tests, and this description.
## Checklist
- [x] Tests cover the change and fail without it
- [x] Lint, format, typecheck and the affected suites pass locally
Does this PR entail a change in behavior?
- [x] Yes — described under Summary above
- [ ] No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(mcp): connect the user's signed-in Chrome through opencli-mcp [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han commented on PR #5638:
URL: https://github.com/apache/maka/pull/5638#issuecomment-5813781402
Thanks, both fixed in f44ff8730.
1. **Windows launch.** `openInChrome` now starts `chrome.exe` from Chrome's install locations (`ProgramFiles`, `ProgramFiles(x86)`, `LOCALAPPDATA` under `Google\Chrome\Application`) and falls back to the default browser only when none starts. The new test runs a stand-in `chrome.exe` for the Windows branch: it receives the store URL and the default browser is not used; with no Chrome found, the default browser gets the URL. As you noted, this is still not a real Windows browser session.
2. **Leftover launcher.** Another install now counts as live only while every absolute path its launcher quotes still exists. The registration test adds a launcher in the upstream `~/.opencli-mcp/bin/` format whose `main.js` is gone: its manifest is replaced with Maka's launcher, while one whose `main.js` exists is still kept.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(mcp): connect the user's signed-in Chrome through opencli-mcp [maka]
Posted by "liuxiaocs7 (via GitHub)" <gi...@apache.org>.
liuxiaocs7 commented on PR #5638:
URL: https://github.com/apache/maka/pull/5638#issuecomment-5813635442
AI-assisted review by Codex of commit `bdc84f33bd0e9648c3de40ec4dfcbc9e14d482df`.
The Chrome icon update follows the existing image-rendering path, and the source inventory checks pass (5/5). Two P2 issues remain in the connection setup:
1. **[P2] Launch Chrome explicitly on Windows** — [opencli-chrome.ts:146–157](https://github.com/apache/maka/blob/bdc84f33bd0e9648c3de40ec4dfcbc9e14d482df/apps/desktop/src/main/opencli-chrome.ts#L146-L157)
`openInChrome()` only defines launch candidates for macOS and Linux. On Windows it always falls through to `shell.openExternal()`. If Chrome is installed but Edge or Firefox is the default browser, clicking **Chrome +** opens the store in that browser instead of Chrome, breaking the intended Chrome extension onboarding flow. Please add Windows Chrome discovery and launch handling, with an appropriate fallback when Chrome is unavailable.
2. **[P2] Detect stale launchers whose target was removed** — [opencli-chrome.ts:135–138](https://github.com/apache/maka/blob/bdc84f33bd0e9648c3de40ec4dfcbc9e14d482df/apps/desktop/src/main/opencli-chrome.ts#L135-L138)
`ownedByAnotherInstall()` treats an existing launcher file as proof of a live installation. However, upstream setup writes its launcher under `~/.opencli-mcp/bin/`; uninstalling the global npm package can leave that launcher and the Chrome manifest behind while removing the referenced `main.js`. Maka then keeps skipping registration, so repeatedly clicking **Connect Chrome** cannot repair the connection.
I reproduced this with a launcher in the upstream format: it ran successfully before its target was removed, then failed with `MODULE_NOT_FOUND`; `registerOpencliNativeHost()` returned `[]` and left the manifest pointing at the broken launcher even though Maka's replacement launcher worked. Please distinguish a usable external installation from a leftover launcher and replace the registration when its referenced target is no longer available.
The Windows routing check used a simulated platform branch, not a real Windows browser session. The existing Windows test only compares the generated `.cmd` text; actual startup coverage would provide stronger confidence.
The adapter boundary looks reasonable, and these fixes should not require a deeper refactor. I recommend addressing both issues before merging. This is an automated review, not an independent human approval.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] feat(mcp): connect the user's signed-in Chrome through opencli-mcp [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
Astro-Han merged PR #5638:
URL: https://github.com/apache/maka/pull/5638
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org