Use the platform from your agent

The platform tools let an agent read your workspace, rebuild, promote, share and submit on extension.dev without opening the console. Reach for this page when you decide what an agent may do on your behalf, and what stays with a person.

Quick start

Start the server with the platform group, then ask the agent to sign in to every project of your workspace:

claude mcp add extension-dev -- npx @extension.dev/mcp --features=local,platform

Sign this machine in to every project of acme on extension.dev, then tell me which projects failed their last build

The agent calls extension_auth with workspace: "acme" and projects: "*". You approve one code at extension.dev/device, the page lists every project it signs in to, and the agent then reads them with extension_workspace.

How it works

Sign in to a project or a workspace

Every login is a project token. It is scoped to one project, stored on this machine, never shown to the agent, and lives at most 7 days. There is no workspace-wide token.

• One project. extension_auth with action: "login" and project: "<workspace>/<project>".
• Several projects. Pass projects with 1 to 20 names in one workspace. One approval stores one token per project, and one missing project refuses the whole list.
• Every project. Pass workspace with projects: "*". The approval page lists the projects the workspace has when you open it, and the answer names each one signed in. A workspace with more than 20 projects, or none, is refused whole, never cut short.

Logins sit side by side. A call uses the most recent one, and project chooses another. extension_auth with action: "status" lists them all and when each expires. Logins that expire together renew with the same call.

What a login reads

A login reads its own project and, through any project of a workspace, that workspace. The platform checks on every call that the account which approved the login is still a member.

• Workspace: the plan, its limits and what is used this month, the members count and your role, every project with its last build per browser, and the period's CI minutes and cost. See extension_workspace.
• Project settings: general settings and build settings per browser, read with that project's own login.
• Builds: recent builds, one build's checks, artifacts and integrity, and its CI log lines per browser. See extension_builds.
• Releases and stores: channels, release history, store configuration, submissions and review state, the Chrome staged rollout, and whether a release pull request could build. See extension_release_status.

Promote readiness and release workflow runs read only with a login approved by a workspace owner.

What a login does

Some acts run at once. A rebuild starts a real CI run on the project's runners. create-channel adds a release channel. extension_shares with action: "create" shares a build as a public link. extension_publish returns the build page URL.

Other acts wait for a person. The first call answers status: "approval-required" with an approval URL, or refuses with the reason before anyone is asked. Once a person approves, the same call with the approvalId runs the act once.

Act	Tool and input	Who approves	Login it needs
Revoke a share	extension_shares, action: "revoke"	Any workspace member	Any
Promote to a channel	extension_release_promote	A workspace owner	Approved by an owner
Submit for store review	extension_submit, dryRun: false	A workspace owner	Approved by an owner
Change build settings	extension_builds, action: "configure"	A workspace owner	Approved by an owner
Open a release pull request	extension_release_promote, action: "cut"	A workspace owner	Approved by an owner
Roll a channel back	extension_release_promote, action: "rollback"	A workspace owner	Approved by an owner
Withdraw a submission from review	extension_submit, action: "cancel"	A workspace owner	Approved by an owner
Raise the Chrome staged rollout	extension_submit, action: "rollout"	A workspace owner	Approved by an owner

A revoke asks by default, and the server flag EXTENSION_DEV_APPROVAL_GATE changes that. The other seven acts always ask an owner, whatever the flag says. See Server flags and telemetry.

The approval page

The approval URL opens on extension.dev and asks you to sign in with GitHub. It names the act, the project and the account that asked. It lists the exact inputs, such as the build, the channel, the store or the rollout percentage. A build settings change lists each setting that changes. Otherwise the page shows the agent's own description of the act.

Approving lets the agent run exactly that act, once, within 15 minutes. Any change to the inputs needs a new approval. A person who is not a member, or a member approving an owner's act, is refused and nothing changes.

What stays in the console

A login never changes these. Make them in the console:

• Billing and the plan, see Usage and limits
• Members, roles and invites, see Workspaces
• Deleting a release, a project or a workspace
• Store credentials, see Credentials
• Environment variables and secrets, see Environments
• The GitHub integration and deployment settings, see Projects
• Minting and revoking access tokens, see Access tokens

extension_workspace answers with links to the workspace's plan, usage and members pages in the console, and to a project's settings page.

Reference

Limit	Value
Login lifetime	7 days at most
Projects per login approval	1 to 20
Approval lifetime	15 minutes, one use
Rebuilds per month	The workspace's build dispatches: 100 on Free, 350 on Pro
Rebuild burst	12 builds in any 60 minutes on Free, 30 on Pro
Channels created per login	20 per hour

A rebuild counts against the same allowance as every other build of the workspace. See Usage and limits.

When it fails

• The answer reads status: "platform-held". extension.dev is not open to the public yet, so nothing ran on its machines. Creating, running and building an extension still work on your machine.
• A read is refused as TokenWorkspaceMismatch. The login belongs to another workspace. Sign in to a project of the workspace you want, or to all of them with projects: "*".
• A read is refused as TokenProjectMismatch. A project's own records read only with that project's login. Sign in to it and pass it as project.
• Every login stops working as MinterNotMember. The account that approved them left the workspace. Sign in again as a current member.
• An approval is refused as ApprovalExpired or ApprovalConsumed. An approval lasts 15 minutes and runs once. Read the current state, then call again with no approvalId if the act did not happen.
• An act answers status: "needs-owner". The login was approved by a member who is not an owner. Ask an owner to sign in and run it, or make the change in the console.
• A rollback is refused with NO_ROLLBACK_TARGET. The channel has served no earlier build. Promote another build to it instead.
• A rollout is refused with ROLLOUT_NOT_STAGED. Chrome publishes this project to everyone at once. Turn on staged publish in the project's Chrome store settings; it applies from the next submission.
• A rebuild answers status: "rate-limited". The workspace spent its monthly builds or its hourly burst. Wait the retryAfterSeconds in the answer.

Next

• Platform tools: login, batch creation, shares and publish
• extension_workspace and extension_builds
• Server flags and telemetry: turn the platform group and the approvals on and off