Deploy applications to Vercel with preview URLs

Deploy to Vercel takes any project and gets it live on Vercel, always as a preview deployment unless the user explicitly asks for production. Before choosing a method it runs four checks: whether a git remote exists, whether the project is already linked to Vercel (a .vercel/project.json from vercel link, or a .vercel/repo.json from vercel link --repo), whether the Vercel CLI is installed and authenticated (vercel whoami), and, if authenticated, which teams are available. Only vercel whoami is safe to run in an unlinked directory to probe state - vercel project inspect, vercel ls, or vercel link will either prompt interactively or, with --yes, silently link the project as a side effect, so they are never used just to detect whether a project is linked. If the user belongs to more than one team, it lists the team slugs and asks which to deploy to, then passes that team as --scope on every following CLI call; a single team or personal account skips the prompt, and an already-linked project reads its team from the orgId already stored in .vercel/project.json or .vercel/repo.json instead of asking again.

Use it for requests like "deploy my app", "deploy and give me the link", "push this live", or "create a preview deployment." The goal beyond the immediate deploy is to move the project toward git-push deploys: a linked project with a git remote deploys by committing and pushing, with Vercel building automatically and non-production branches getting preview deployments. When linking a project for the first time, vercel link --repo is preferred over plain vercel link whenever a git remote exists - it matches the repo to an existing Vercel project by remote URL, while plain vercel link matches by local directory name and often fails when the folder and the Vercel project are named differently. It explicitly avoids ever pushing without asking first, and it never curls or fetches the deployed URL to verify the site works - it only returns the link.

Input is the project path (or a .tgz archive) and, where relevant, a chosen team scope. Output is always the deployment URL: retrieved from vercel ls --format json after a git push, printed directly by vercel deploy --no-wait (with vercel inspect <deployment-url> available afterward to check build status), or, for the no-auth fallback, both a Preview URL for the live site and a Claim URL to transfer the deployment into a real Vercel account.

The Vercel CLI (vercel), installed with npm install -g vercel if missing, authenticated via vercel login. When the CLI cannot be installed or authenticated - the claude.ai sandbox, or a Codex sandbox with no stored credentials - it falls back to a bundled deploy script that needs no authentication, auto-detects the framework from package.json, packages the project excluding node_modules, .git, and .env, uploads it, and waits for the build:

vercel deploy [path] -y --no-wait --scope <team-slug>

If a deploy fails from network restrictions on claude.ai, the fix is adding *.vercel.com to the allowed domains in claude.ai settings; in a sandboxed Codex environment, the same failure is handled by rerunning only the deploy command (never the CLI-availability check) with escalated network permissions.

Anyone working with an agent that needs to ship a working preview or production URL for a project, whether or not Vercel is already configured, and whether or not the environment allows shell login at all.