Skip to content

v10.13.0

Choose a tag to compare

@github-actions github-actions released this 17 Oct 10:34
· 327 commits to main since this release

Built on Extension.js 4.1.33.

  • The package exports @extension.dev/mcp/hosted for running the platform tools on a server. registerHostedTools adds them to an MCP server instance, and createHostedServer builds one. Both take a request credential: the caller's token, the platform base, and the projects that token covers. The hosted set is extension_auth (status only), extension_workspace (info, projects and settings), extension_project_create (one project per call), extension_builds, extension_release_status and extension_release_promote. Login, logout, publish, submit, share links and every local tool stay out of it. No hosted tool takes api or projectPath, and a call that passes one is refused before any request is sent.
  • Under a request credential, the platform tools send that token and read no stored login, EXTENSION_DEV_TOKEN or EXTENSION_DEV_PROJECT. Writing or removing a stored login is refused, and nothing is written to the login store. The local server still reads auth.json as before.
  • Under a request credential, every call to the platform names its project in the x-extensiondev-project header: the project the call passes as project when the credential covers it, else the first project it covers. One connected-app token can cover several projects, and the platform needs the header to know which one a call is for. A 401 from the platform during the call is reported to the host through onUnauthorized, so it can ask the client to sign in again.
  • Under a request credential, extension_auth status describes the connection instead of a stored login: it names the project the connection's token is signed in to, and its warning says the connection renews on its own and can be revoked under the project's Settings, Connected apps. It no longer says that CLI tokens last 7 days or that CI must re-mint them.
  • extension_builds with action: "rebuild" asks for a workspace owner's approval when the platform requires one, as it does for a rebuild started through a connected app: the first call answers approval-required with the approval URL and the exact commit and environment the platform resolved, and the same call with that approvalId, buildId set to the full commit sha and the same buildEnv starts the run once. A rebuild with an approvalId and a short or missing commit is refused before anything is sent. A used approval says the run may already exist and to read action: "list" first. A rebuild with a CLI login still starts at once.
  • The project id that platform tools look up for a token is now cached under a hash of the server, the token and the project, never the token itself, and the cache keeps at most 512 entries.