## TL;DR
snyk reads the .snyk policy file from the directory of the project being tested, not from wherever you invoked it. Running snyk test from the repo root against a package in packages/app never loads packages/app/.snyk, so every ignore in it is silently skipped. Run snyk from the project directory, or pass --policy-path pointing at the right file, and verify the ignore actually applied.

## The query

```text
snyk ran from the repo root ignored the .snyk policy file in the package subdirectory
```

## Use this when

- Ignores in a subdirectory .snyk file never take effect
- snyk runs from the repo root in a monorepo
- The same .snyk works when you cd into the package directory manually

## Not for

- snyk not finding the project at all (detection problem)
- A malformed .snyk file (snyk would warn, not silently skip)
- Ignores that apply but you disagree with (triage decision)

## Steps

### 1. Find every .snyk file in the repo

```bash
find . -name ".snyk" -not -path "*/node_modules/*"
```

Expected output: the full list of policy files and where they live. Surprises here are the norm in monorepos.

### 2. Run the test from the project directory

```bash
cd packages/app && snyk test
```

Expected output: the ignores from packages/app/.snyk now apply. Compare the issue count against the root run; the difference is what was being skipped.

### 3. Or point at the policy explicitly

```bash
snyk test --file=packages/app/package.json --policy-path=packages/app/.snyk
```

Expected output: same suppressed result as step 2, without changing directories. Useful in CI where the working directory is fixed.

### 4. Verify the ignore positively

Pick one ignored CVE, run the scan without the policy path, confirm the CVE appears, then run with it and confirm it disappears.

Expected output: proof the policy file is the thing doing the suppressing.

### 5. Encode per-project scans in CI

Make the pipeline loop over project directories (or declare them explicitly) instead of one root-level snyk test. Verify: each project's scan loads its own .snyk, and a root-only run is either removed or documented as partial.

## Variant phrasings

### snyk policy file subdirectory ignored
The short symptom search.

### snyk .snyk not applied monorepo
The monorepo-shaped search.

Compatibility: snyk CLI with .snyk policy files; monorepos with npm, yarn, or pnpm workspaces.

## Why it happens
snyk scopes a test to one project directory and loads that directory's policy file. The invocation directory is just where the command started, not the project under test. In a monorepo the two are different, and snyk does not go hunting upward or sideways for policy files; it only looks in the project directory.

## Edge cases / pitfalls

- A .snyk at the repo root applies to root-level scans only. It does not cascade into package directories.
- --all-projects changes the scoping rules. If you use it, verify per-project which policy file each sub-scan loaded.
- Stale .snyk files in deleted package directories are harmless but confusing. Prune them when you restructure.
- Document which policy file governs each project in the repo readme or the CI config. The next person will otherwise "fix" the duplication by deleting the wrong one.

## Provenance

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