Short answer: no for the CLI, yes for jobs. The dbt Cloud CLI, now the dbt platform CLI, runs the project in your local folder, including changes you have not committed. Deploy jobs and CI jobs never see your folder: they run the code in the Git repository. A fix that works with the CLI reaches production only after it is pushed and merged.
Copy and paste
Where each way of running dbt takes its code from:
| Running from | Code | Writes to | Needs a commit and push |
|---|---|---|---|
| dbt platform CLI | your local folder | your development schema | no |
| Studio IDE | the IDE’s copy of your branch | your development schema | no to run; yes to share |
| CI job | the pull request’s branch | a temporary dbt_cloud_pr_ schema |
yes, pushed to the pull request |
| Deploy job | the environment’s branch, the default branch unless a custom one is set | the environment’s schemas | yes, merged into that branch |
Check it on your own project:
git status # a new model you have not committed
dbt compile -s my_new_model # the CLI compiles it anywayWhy a fix passes locally and fails at night
- You fix a model and run
dbt build -s my_modelwith the CLI. It passes, because the CLI ran your local file. - You forget to push, or the pull request is still open.
- The nightly deploy job checks out the environment’s branch, which still has the old code, and fails again.
The job’s run log shows the Git commit it ran. Compare it with your local git log when a job behaves
differently from your terminal.
Development and production credentials
The CLI connects with your development credentials and builds into your development schema, reading unchanged models from production through deferral. A deploy job uses the deployment environment’s credentials and writes to the production schemas. Even with the same code, the two can differ when your role cannot see a table that the production role can.
Things to know
- The Studio IDE works on its own copy of your branch in dbt platform. Use Commit and sync to share changes, and to get changes made elsewhere.
- Custom branch. A deployment environment can run a branch other than the default, for example
release. Check the environment’s settings when a merged change does not appear. - Packages. The CLI does not support relative paths in
packages.yml, such aslocal: ../shared. Use a Git or hub package instead.
Based on the dbt platform documentation and on how the CLI is designed to work (October 2026); not run against a live dbt account. The check above confirms it on your project in one command.
