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

> Trace a local Canopy agent change through GitHub, v0's base and working branches, Pull Changes, preview deployments, and production permissions.

Canonical HTML: https://canopyide.dev/guides/v0-not-showing-local-github-changes
Article date: 2026-09-28

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.

````text
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.

## Sources and further reading

- [v0 GitHub: base, working, and production branches, previews, Pull Changes, and permissions](https://v0.app/docs/github)
- [v0 deployments](https://v0.app/docs/deployments)
- [Vercel environment variables for local development](https://vercel.com/docs/environment-variables)
- [Vercel preview and production environments](https://vercel.com/docs/deployments/environments)
- [Canopy README: local CLI, Servers, Preview, and Git review](https://github.com/FluidWorksApp/canopy-ide/blob/main/README.md)
- [Public report about v0 pulling an external coding-agent PR](https://www.reddit.com/r/v0_/comments/1t07gdg/v0_awful_at_pulling_in_repo_changes_from_git_if/)

## Related Canopy pages

- [Work on a Lovable app locally in Canopy without losing Git sync](https://canopyide.dev/guides/lovable-to-canopy-local-coding-agent-workflow.md)
- [Keep building a Bolt app with local coding agents in Canopy](https://canopyide.dev/guides/bolt-to-canopy-local-coding-agent-workflow.md)
- [Canopy vs Replit Agent for building an app](https://canopyide.dev/use-cases/canopy-vs-replit-agent-for-building-apps.md)
- [My coding agent edited the wrong branch or worktree. What now?](https://canopyide.dev/guides/coding-agent-edited-wrong-branch-or-worktree.md)
- [How to review an AI-generated pull request](https://canopyide.dev/guides/review-ai-generated-pull-requests.md)

Canopy runs installed coding CLIs; CLI accounts, model selection, and provider billing remain separate. Check the installed release before relying on version-specific behavior.