# Sentry: sentry-cli fails on org or project scope
## The error
Commands fail with not-found or permission errors even though the auth token works (`sentry-cli info` succeeds). The CLI is talking to the wrong org or project.
## How scoping works
The CLI resolves org/project from, in precedence order:
1. Explicit flags: `--org`/`-o`, `--project`/`-p`
2. Env vars: `SENTRY_ORG`, `SENTRY_PROJECT`
3. `.sentryclirc` `[defaults]` section (found by searching upward from cwd, plus `~/.sentryclirc`)
4. `.properties` files via `SENTRY_PROPERTIES`
A stale `.sentryclirc` in a home directory or repo root silently overrides what you think you exported. When scope looks wrong, print the resolution: check env first, then look for `.sentryclirc` files upward from the working directory.
## The releases quirk
Release commands split the scope across levels:
```
sentry-cli releases -o [your org] new -p [your project] [version]
```
Org goes on `releases`, project goes on the subcommand (`new`, `set-commits`, `deploys`). Putting `-p` on the outer command is silently ignored for these subcommands, and the release lands on the wrong project or fails.
## Fix and verify
Set `SENTRY_ORG` and `SENTRY_PROJECT` explicitly in CI rather than relying on config files, and pass `--org`/`--project` explicitly in scripts that touch multiple projects. Re-run `sentry-cli info` and confirm the org slug matches the URL you see in sentry.io. Slugs are not names: the slug is the URL-safe identifier in settings, and using the display name fails.