## TL;DR

Editing packages.yml changes intent, not the installed code: dbt runs whatever is in dbt_packages until dbt deps runs. Run dbt deps after any packages.yml edit, confirm the installed package version in dbt_packages, and recompile. In automation, chain deps before parse or run whenever packages.yml changed (or always, it is idempotent).

```text
agent skipped dbt deps after editing packages.yml: stale dbt_utils
```

## Use this when

- packages.yml shows a new dbt_utils (or other package) version but behavior matches the old one
- an agent edited packages.yml and went straight to dbt run or dbt compile
- dbt_packages folder timestamps predate the packages.yml edit

## Not for this skill when

- dbt deps was run and fails with a version conflict, resolve the constraints instead
- the package is installed from a local path, edits there apply without deps; check the package source type
- behavior difference comes from your override macro, not the package version

## Steps

1. Compare intent versus installed: read the version in packages.yml for the package, then check the installed copy (its dbt_project.yml or version file inside dbt_packages for that package, or the lock file package-lock.yml if present).
   Verify: intended and installed versions are both known and their mismatch is confirmed.

2. Run dbt deps and watch its output list the package at the intended version. If a package-lock file is in use, confirm it updates consistently.
   Verify: deps completes and the lock or installed version matches packages.yml.

3. Run dbt parse, then compile a model that uses a macro whose behavior changed between the versions, and diff the compiled SQL against expectations.
   Verify: compiled SQL reflects the new package behavior.

4. Fix the agent procedure: any change to packages.yml must be followed by dbt deps in the same task, and CI should run deps before build steps unconditionally.
   Verify: the workflow runs deps automatically and the stale state cannot recur silently.

## Variant phrasings

### deps succeeds but old code persists in Cloud
dbt Cloud caches dependencies per environment in some setups; trigger a fresh job or clear the environment state if the version still lags.

### git package pinned by revision
For git packages, deps resolves the revision in packages.yml or the lock; bumping a branch name without deps keeps the old checkout. Deps is still the step that moves it.

Compatibility: dbt deps and packages.yml (hub and git packages), package-lock.yml on dbt-core 1.7 and later workflows. Installed code lives in dbt_packages by default (configurable via packages-install-path).

## Why it happens

dbt separates declaring dependencies from installing them, exactly like a package manager lock workflow. The runner never re-resolves packages.yml on its own, so an edited declaration with no install step is a no-op that looks like a completed upgrade. Agents that treat file edits as state changes fall for this because the file really did change; the system state did not.

## Edge cases / pitfalls

- A stale dbt_packages can also mask the reverse bug: code written against new macros fails mysteriously on the old installed package.
- Commit package-lock.yml where your team uses it, so deps results are reproducible across agents and CI.
- Vendored or local packages bypass deps semantics; mixing them with hub packages in one project needs a written convention.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_U0aQPub8JLhDiHQsEM7zOg