Problem
Local's site overview includes a WP Admin button that opens /wp-admin already authenticated — no typing credentials. Great UX, but the code path is private. Add-ons cannot:
- Hand a user a clickable magic-link URL for
/wp-admin (e.g. an MCP server returning a link to its chat client at the end of an automated task).
- Drive an authenticated browser session against
/wp-admin (e.g. for Playwright-driven verification, screenshots, automated admin workflows).
I confirmed the absence by walking the documented surface area at https://build.localwp.com/ and https://getflywheel.github.io/local-addon-api/:
ServiceContainerServices lists ~40 cradle services. None is auth-related.
browserManager only exposes openInBrowser(url: string): void and getAvailableBrowsers().wpCli, siteShellEntry, graphql etc. have nothing relevant.
- The renderer module exports only
ipcAsync and confirm. No IPC channels are documented for the WP Admin button.
- A direct query against
master.md?ask= confirms it verbatim: "I cannot find a documented way to open wp-admin programmatically from the add-on Main entry point" and "The docs here do not describe any built-in wp-admin auto-login flow."
Recommended API
A new cradle service mirroring the patterns of siteProcessManager:
```ts
interface AdminLogin {
/**
- Generates a one-time URL that lands the requester in /wp-admin already authenticated.
- Equivalent to the code path behind Local's "WP Admin" button.
- @param site - the Local Site
- @param opts.user - WordPress user_login or email; defaults to the first administrator
- @returns a fully-qualified URL string
- @throws if the site is halted or the user does not exist
*/
generateLoginUrl(site: Site, opts?: { user?: string }): Promise;
}
```
Exposed on the cradle as `adminLogin` (name negotiable). The add-on calls:
```ts
const url = await LocalMain.getServiceContainer().cradle.adminLogin.generateLoginUrl(site, { user: 'jane' });
```
Behavior expectations
- Returns a URL that, when opened in any browser, lands the user on `/wp-admin` without typing credentials. (Same as the WP Admin button.)
- If `opts.user` is omitted, defaults to the first administrator.
- Rejects clearly if the site is halted, or the requested user does not exist.
Why a public API matters
The surface of MCP / agentic tooling around Local is growing rapidly. Add-ons want to hand a clickable login URL back to AI agents so the human can verify changes in `/wp-admin` with one click — or so the agent itself can drive an authenticated Playwright session. Today every add-on that wants this has to either probe Local's private internals or reinvent magic-login via wp-cli + a mu-plugin, which both fragments the ecosystem and duplicates code that already exists inside Local.
References
Problem
Local's site overview includes a WP Admin button that opens
/wp-adminalready authenticated — no typing credentials. Great UX, but the code path is private. Add-ons cannot:/wp-admin(e.g. an MCP server returning a link to its chat client at the end of an automated task)./wp-admin(e.g. for Playwright-driven verification, screenshots, automated admin workflows).I confirmed the absence by walking the documented surface area at https://build.localwp.com/ and https://getflywheel.github.io/local-addon-api/:
ServiceContainerServiceslists ~40 cradle services. None is auth-related.browserManageronly exposesopenInBrowser(url: string): voidandgetAvailableBrowsers().wpCli,siteShellEntry,graphqletc. have nothing relevant.ipcAsyncandconfirm. No IPC channels are documented for the WP Admin button.master.md?ask=confirms it verbatim: "I cannot find a documented way to open wp-admin programmatically from the add-on Main entry point" and "The docs here do not describe any built-in wp-admin auto-login flow."Recommended API
A new cradle service mirroring the patterns of
siteProcessManager:```ts
interface AdminLogin {
/**
*/
generateLoginUrl(site: Site, opts?: { user?: string }): Promise;
}
```
Exposed on the cradle as `adminLogin` (name negotiable). The add-on calls:
```ts
const url = await LocalMain.getServiceContainer().cradle.adminLogin.generateLoginUrl(site, { user: 'jane' });
```
Behavior expectations
Why a public API matters
The surface of MCP / agentic tooling around Local is growing rapidly. Add-ons want to hand a clickable login URL back to AI agents so the human can verify changes in `/wp-admin` with one click — or so the agent itself can drive an authenticated Playwright session. Today every add-on that wants this has to either probe Local's private internals or reinvent magic-login via wp-cli + a mu-plugin, which both fragments the ecosystem and duplicates code that already exists inside Local.
References