Deploy applications to Vercel with preview URLs

Deploy to Vercel deploys a project to Vercel, always as a preview unless the user explicitly asks for production, and steers toward the best long-term setup - a project linked to Vercel with git-push deploys. It first checks project state - a git remote, an existing .vercel/project.json or .vercel/repo.json link, whether the CLI is authenticated via vercel whoami, and available teams - warning that only vercel whoami is safe to run in an unlinked directory since other commands can silently link as a side effect. It then picks a method from four states: linked with a git remote, ask before committing and pushing, since Vercel auto-builds from the push and reports the preview URL via vercel ls --format json; linked without a remote, vercel deploy --no-wait, checked with vercel inspect; not linked but authenticated, ask which team, then vercel link --repo when a remote exists, more reliable than plain vercel link, which matches by directory name, or plain vercel link otherwise, then deploy; and not linked and not authenticated, install the CLI, vercel login, then link and deploy. When the user belongs to multiple teams, it presents the team slugs once and passes the chosen one via --scope on every subsequent command without re-confirming. Two no-auth fallbacks exist for sandboxed environments that can't authenticate: a claude.ai sandbox script (resources/deploy.sh) and a Codex sandbox script (resources/deploy-codex.sh), each auto-detecting the framework, packaging the project while excluding node_modules, .git, and .env, and returning both a live Preview URL and a Claim URL to transfer the deployment into the user's own account. It always surfaces the deployment URL to the user and explicitly never curls the deployed URL to verify it works.

Use it when the user asks to deploy an app or website - "deploy my app," "deploy and give me the link," "push this live," or "create a preview deployment." Agent-specific routing matters: terminal-based agents with full shell access follow the CLI decision flow directly; claude.ai's sandbox generally can't run vercel login or git push and should go straight to its no-auth fallback; Codex should check CLI availability first and fall back to its own deploy script, escalating network permissions only for the actual deploy command, never the availability check. On a network egress failure in claude.ai, the fix is adding *.vercel.com to allowed domains in capability settings; on CLI auth failure, fall back to the appropriate no-auth script.

Input: a project directory, or a .tgz tarball for the no-auth path, git remote and Vercel-link state, and, if relevant, a chosen team slug. Output: a deployment URL, preview by default, production only if asked, reported via vercel ls, the CLI's own deploy output, or, for the no-auth fallbacks, both a Preview URL and a Claim URL.

• Vercel CLI (vercel deploy, vercel link, vercel link --repo, vercel ls, vercel inspect, vercel teams list, vercel login, vercel whoami)
• Git, for the git-push deploy path
• Bundled fallback scripts resources/deploy.sh for claude.ai and resources/deploy-codex.sh for Codex, for sandboxes that can't authenticate

Anyone asking an agent to deploy a project to Vercel, across terminal, claude.ai sandbox, or Codex environments, who wants the agent to pick the right deploy path automatically and move the project toward a properly linked, git-connected setup.