v0 not showing your local agent's GitHub changes? Check the branches

A merged pull request can be in GitHub while an open v0 chat still previews its own working branch. v0 distinguishes the repository's default branch, the chat's base branch, its generated working branch, and Vercel's production branch. Before asking either agent to redo the change, identify those four branch roles and the exact commit each preview shows. The repair may be to merge into the expected base, select Pull Changes in v0, or wait for a preview deployment—not to generate the same feature twice.

Map v0's four branch roles

v0's current GitHub guide says each GitHub-connected chat starts from a selected base branch. Its first generated code change creates a working branch for that chat, and v0 pushes there rather than directly to the base. A separate Vercel production branch controls production deployments. The repository's default branch is usually selected at import, but the chosen base and production branch can differ from it. A local coding agent in Canopy has its own checked-out branch. Seeing a PR merged to `main` therefore does not prove that an open v0 working branch already contains it, or that the production URL deployed it.

Record the actual names in your project; `main` is only an example.
Role	Where to inspect	What it answers
Default branch	GitHub repository settings	What a fresh import usually selects
v0 chat base	v0 chat Git branch menu	Where that chat's PR targets
v0 working branch	v0 branch menu and GitHub PR	Which generated edits its preview contains
Production branch	Linked Vercel project settings	Which Git commits can trigger production

Verify the local result and the PR first

Open the connected GitHub repository locally in Canopy, record the starting commit, and give an installed CLI one bounded edit. Use a separate feature branch and a small acceptance check, such as fixing a sign-up form's retry state without changing its database schema. Start the real project command in Canopy Servers, test the local URL in Preview, read the diff, and open a GitHub PR. Check the PR base branch and the merged commit before diagnosing v0. A PR that targeted another release branch has not changed this v0 chat's base. A local Preview is also separate from the v0 branch's Vercel preview deployment; compare both against the same acceptance check and commit.

Do not let the local agent edit v0's active working branch while v0 is also changing it; review the changes through your own PR.
Record the PR base, head, merge commit, and the branch v0 calls its base.
If the GitHub PR is still open or checks failed, finish that review before expecting the merged result in v0.

Bring a merged base change into the open v0 chat

When the local PR has merged into the v0 chat's base branch, open that chat's branch menu. v0 documents Pull Changes for bringing newer base commits into the working branch. It is enabled only when the base has commits missing from the chat, and merge conflicts must be resolved first. Check the branch diff and latest preview deployment after pulling. If the chat has no active preview, v0 says a code change must first be pushed to its working branch; the absence of a preview by itself does not mean the GitHub merge disappeared. If the chat was already published, v0 synchronizes it back to its updated base, and the next generated edit starts another working branch. Inspect the current state instead of assuming the old branch still owns the chat.

If Pull Changes is unavailable, compare base and working commits; it may have nothing new to pull.
If conflicts or CI failures block the path, use the branch menu and inspect the resulting diff and checks rather than treating an agent's repair claim as final.
A separate v0 chat is a separate stream of work with its own base and working branch; do not use another chat's preview as evidence for this one.

Check the environment and deployment separately

v0's GitHub integration is tied to Vercel previews and production deployment. Its guide says each working branch receives a preview deployment, while Publish creates or reuses a PR, merges it into the chat's base, and waits for production deployment. GitHub rules such as required checks and human review can block that publish flow. The exact public deployment also depends on the linked Vercel project's production branch. Before local testing, inspect the project's README and scripts and obtain only the development environment variables authorized for that project; Vercel documents `vercel env pull` for the Development environment. A local clone does not include hosted secret values or make production data safe for tests. Use a test account and check the backend target. A local build, v0 preview, Vercel preview URL, and production URL can represent different commits or environment variables.

Do not call the change live until the last boundary is verified.
Boundary	Evidence	Common mismatch
Canopy local run	Checked-out commit, run command, local behavior	Missing Development variables or wrong backend
GitHub PR	Merged commit and intended base	PR targeted a different branch
v0 chat	Base/working branch diff and Pull Changes result	Open working branch is behind base
Vercel preview	Deployment URL and commit	Build or permissions block preview
Production	Production branch and live URL behavior	Merge or publish did not deploy

Handle a permissions or source-of-truth failure

v0 says a connected GitHub repository becomes the source of truth for project code; deleting it can make that code unrecoverable. Repair a missing repository connection in v0 project settings, not by starting a second unrelated repository. If v0 Publish is blocked by branch protection, complete the required checks or review in GitHub and retry. The v0 web app and a GitHub-triggered Vercel deployment can also use different permissions: v0 roles govern v0 actions, while Vercel roles govern GitHub or CLI deployments. If a PR merge succeeded but a deployment is missing, inspect the Vercel project and the actor's permission rather than asking the coding agent to recreate the code. Keep a small handoff with commit IDs and links so the next person can diagnose from evidence.

Preserve the repository and branch history while investigating a missing preview.
Check whether the v0 chat, GitHub repository, and Vercel project belong to the same team and project.
Ask for a human review when branch rules require it; an AI fix cannot substitute for that approval.

Copyable resources

v0 Git handoff and missing-change checklist

Copy branch names and commit IDs, not secret values or private data.

v0 chat URL and linked GitHub/Vercel project: [ ]
GitHub default branch: [ ]
v0 chat base branch and working branch: [ ]
Vercel production branch: [ ]
Canopy local checkout, CLI, starting commit: [ ]
Local run command, URL, backend target, acceptance result: [ ]
PR head, base, checks, and merge commit: [ ]
v0 Pull Changes available/result: [ ]
v0 branch diff and preview deployment commit/URL: [ ]
Vercel preview and production deployment commit/URL: [ ]
Missing permission, conflict, or environment value (name only): [ ]
Reviewer, next action, and verified outcome: [ ]

Frequently asked questions

Why does my v0 chat miss a PR merged to GitHub?

Check whether the PR merged into that chat's base branch. An open v0 working branch may need Pull Changes before its preview contains new base commits.

Does v0 push generated code directly to main?

Its current GitHub workflow creates a working branch from the chat's base for generated code and uses a PR to merge it. Check your project's configured branch names.

Does a successful local Canopy preview mean v0 or production is updated?

No. Verify the GitHub merge, the v0 branch and preview deployment, and the Vercel production deployment as separate states.

Why can I publish in v0 but not deploy through a GitHub push?

v0 roles govern actions in the v0 web app; GitHub-triggered and CLI deployments use Vercel project permissions. Inspect the actor's Vercel role and project access.

Can I run the v0 project locally without production secrets?

Use the repository's run instructions and authorized Development environment variables. Vercel documents `vercel env pull` for local Development values; check the backend target and use safe test data.

Browse more Canopy questions →