# Protected Vercel Deployments

Access and test Vercel deployments protected by Vercel Authentication, SSO, or...

- Repository: https://github.com/vercel-labs/agent-browser (45133 stars)
- Category: Testing
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add vercel-labs/agent-browser --skill protected-vercel-deployments -g -a claude-code -y`
Codex: `npx skills add vercel-labs/agent-browser --skill protected-vercel-deployments -g -a codex -y`
Cursor: `npx skills add vercel-labs/agent-browser --skill protected-vercel-deployments -g -a cursor -y`
Gemini CLI: `npx skills add vercel-labs/agent-browser --skill protected-vercel-deployments -g -a gemini-cli -y`
Claude Code plugin marketplace: `/plugin marketplace add vercel-labs/agent-browser`

## Description

Access and test Vercel deployments protected by Vercel Authentication, SSO, or Deployment Protection with agent-browser. Use when a preview or production URL redirects to a Vercel login page, returns a protection 401 or 403, or needs short-lived Trusted Sources OIDC authentication instead of a static bypass secret or public exception.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Protected Vercel deployments

Use the caller's existing Vercel identity and a short-lived OIDC token. Do not disable Deployment Protection, make the deployment public, or ask for a static bypass secret first.

## Same-project preview

A local development token for the target project can access that project's protected Preview deployments through the default Trusted Sources self-access rule. No Trusted Sources configuration is normally required.

Confirm the local identity and Vercel CLI version:

```bash
vc whoami
vc --version
```

Require Vercel CLI `53.3.0` or newer before running `vc project token`. Versions `50.25.0` through `53.2.x` write the token to stderr, so command substitution captures nothing and the credential can appear in logs. If the installed version is older, stop and ask the user to upgrade it. Do not attempt to capture or recover the token from stderr.

Set the target project and scope explicitly. If they cannot be inferred safely, ask the user. In a directory whose existing `.vercel/project.json` link has been verified against the target, `vc project token` without a project name is also valid. Do not run `vc link` merely to get an OIDC token: current Vercel CLI versions also pull development variables into `.env.local` when linking.

Create a named browser session, mint a development OIDC token with the Vercel CLI, then inject it without printing or persisting it:

```bash
export AGENT_BROWSER_SESSION="$(agent-browser session id --scope worktree --prefix vercel-preview)"
export VERCEL_PREVIEW_URL="https://my-app.vercel.app"
export VERCEL_PROJECT="my-app"
export VERCEL_SCOPE="my-team"

(
  TOKEN="$(vc project token "$VERCEL_PROJECT" --scope "$VERCEL_SCOPE")"
  test -n "$TOKEN"
  agent-browser open "$VERCEL_PREVIEW_URL" --headers \
    "{\"x-vercel-trusted-oidc-idp-token\":\"$TOKEN\"}"
)

agent-browser snapshot -i
```

The rest: https://github.com/vercel-labs/agent-browser/blob/HEAD/skill-data/protected-vercel-deployments/SKILL.md