Access and test Vercel deployments protected by Vercel Authentication, SSO, or Deployment Protection. Use when curl, agent-browser, Playwright, or another automated request reaches a Vercel login or protection page; when a protected preview or production URL returns 401 or 403; when TRUSTED_SOURCES_ENVIRONMENT_MISMATCH appears; or when choosing between `vercel curl` and the `x-vercel-trusted-oidc-idp-token` header.
npx skills add https://github.com/vercel/vercel-plugin --skill access-protected-vercel-deployment
Use the caller's existing Vercel authentication. Do not disable Deployment Protection or ask for a long-lived bypass secret as the first solution.
vercel curlFor response bodies, headers, health checks, and API calls, replace raw curl with vercel curl (vc curl). It accepts native curl options and uses Vercel authentication to access protected preview and production deployments.
vc curl https://my-app.vercel.app/api/health
vc curl https://app.example.com/api/health
vc curl my-app.vercel.app/api/users -X POST \
-H "Content-Type: application/json" \
-d '{"name":"Ada"}'
vc curl /api/health
The path-only form targets the linked project's production deployment. Pass a full URL when the exact deployment matters.
If authentication fails, check the local identity and project before changing protection settings:
vc whoami
Inspect .vercel/project.json to confirm the linked project and team. Run vc link only when the directory is not linked or is linked to the wrong project. Run vc login only when the CLI reports that no authenticated user is available.
Browser requests must include the short-lived local token as a request header:
x-vercel-trusted-oidc-idp-token: <VERCEL_OIDC_TOKEN>
Use a browser tool that supports origin-scoped request headers. With agent-browser, inject development variables without printing or persisting the token:
vc env run -- sh -c \
'test -n "$VERCEL_OIDC_TOKEN" && agent-browser open "$1" --headers "{\"x-vercel-trusted-oidc-idp-token\":\"$VERCEL_OIDC_TOKEN\"}"' \
sh https://my-app.vercel.app
Then continue the normal browser workflow in the same session. For Playwright or another browser driver, set the same header in the browser context's extra HTTP headers before the first navigation.
If the local CLI version does not provide the token through vc env run, refresh local development credentials with:
vc env pull .env.local --yes
Load the file through the project's existing dotenv mechanism. Never print the token, paste its value into source code, or commit .env.local.
Use x-vercel-trusted-oidc-idp-token for Trusted Sources. Do not substitute x-vercel-oidc-token; that header carries an OIDC token into a Vercel Function and serves a different purpose.
A local development token for a linked Vercel project can access that same project's Preview deployments by default. It does not automatically access protected Production deployments. For protected Production, the project's own Trusted Sources entry must allow development → production.
Do not ask the user to configure Trusted Sources for the normal same-project Preview case.
Configuration is needed when:
TRUSTED_SOURCES_ENVIRONMENT_MISMATCH.In the target project, open Settings → Deployment Protection → Trusted Sources. Add or edit the caller and allow the required from → to environment pair. A local token has the development environment, so access to protected Production requires development → production.
Treat this as an access-control change: explain the exact rule required and obtain authorization before changing it. Do not broaden unrelated environment pairs.
TRUSTED_SOURCES_ENVIRONMENT_MISMATCH means the token is valid but its caller environment is not allowed to reach the target environment.401 or 403 after Vercel protection is bypassed belongs to the application's own authentication and must be debugged separately."target": "production" can still be protected. Do not assume production is public.curl repeatedly after receiving the protection page.vc curl or an origin-scoped OIDC header can authenticate the request.VERCEL_OIDC_TOKEN in logs, screenshots, committed files, or user-facing output.⤳ skill: vercel-cli⤳ skill: verificationAzure Resource Manager SDK for Microsoft Playwright Testing in .NET.
Run agent-browser on AWS Bedrock AgentCore cloud browsers. Use when the user wants to use AgentCore, run browser automation on AWS, use a cloud browser with AWS credentials, or needs a managed browser session backed by AWS infrastructure. Triggers include "use agentcore", "run on AWS", "cloud browser with AWS", "bedrock browser", "agentcore session", or any task requiring AWS-hosted browser automation.
Pro frontend engineering discipline. Enforces build-test-verify workflow for every web project. Never declare done until the site is built, tested, responsive, accessible, and visually verified in a real browser. Pairs with a deployment skill such as vercel-cli, where one is installed.
Production-ready CI/CD configurations for Playwright — GitHub Actions, GitLab CI, CircleCI, Azure DevOps, Jenkins, Docker, parallel sharding, reporting, code coverage, and global setup/teardown.
Deploy serverless browser automation as cloud functions using Browserbase. Use when the user wants to deploy browser automation to run on a schedule or cron, create a webhook endpoint for browser tasks, run automation in the cloud instead of locally, or asks about Browserbase Functions.
Run Playwright tests at scale using Azure Playwright Workspaces (formerly Microsoft Playwright Testing). Use when scaling browser tests across cloud-hosted browsers, integrating with CI/CD pipelines, or publishing test results to the Azure portal.
Expert knowledge for Playwright Workspaces development including troubleshooting, best practices, decision making, limits & quotas, security, and configuration. Use when managing Playwright Testing workspaces, tokens/RBAC, quotas, monitoring/metrics, or run/AADSTS7000112 issues, and other Playwright Workspaces related development tasks. Not for Azure App Testing (use azure-app-testing), Azure DevOps (use azure-devops), Azure Pipelines (use azure-pipelines), Azure Test Plans (use azure-test-plans).
| Uses Lovable MCP (preferred) or browser automation to submit deployment prompts. Runs verification tests based on configuration. Auto-deploys after git push when enabled.
Take vercel/access-protected-vercel-deployment from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.