There is no nx cache clean command, which is the first thing to know when a search for one brings you here. The command is nx reset, it does more than empty the cache, and half the time "clear the cache" is not the fix you actually need. This is the complete map: what each reset flag clears, where the cache lives, how to skip it for a single run instead, and the cases where clearing anything is treating the symptom.
nx reset and its flags
Run without flags, nx reset clears three separate things: the local task cache, the workspace metadata Nx computes about your project graph, and the Nx daemon process. Each has its own flag when you want to be surgical (Nx accepts the camelCase spellings such as --onlyCache too):
npx nx reset # cache + workspace data + stop the daemon
npx nx reset --only-cache # clear only the cached task outputs
npx nx reset --only-workspace-data # clear only cached project-graph metadata
npx nx reset --only-daemon # only stop the daemon (it restarts on demand)Knowing which one you need saves real time in a big workspace. Stale task outputs call for --only-cache. A project graph that does not reflect a file you just created - or a task that seems to run against old configuration - is workspace data or daemon state, not the task cache, so --only-workspace-data or --only-daemon is the targeted fix and your cached build outputs survive.
Where the cache actually lives
The local task cache is a plain directory: .nx/cache in the workspace root (older Nx versions used node_modules/.cache/nx). Deleting it by hand is equivalent to nx reset --only-cache:
rm -rf .nx/cache # same effect as nx reset --only-cache
rm -rf .nx/workspace-data # same idea for the project-graph metadataThe location is configurable - cacheDirectory in nx.json or the NX_CACHE_DIRECTORY environment variable - which matters on CI runners where you may want the cache on a faster disk, or outside a checkout directory that gets wiped between jobs. If a teammate's "clear the cache" advice did nothing, check whether the workspace has moved the directory.
Skipping the cache is usually what you wanted
Most of the time the real goal is "prove this task actually executes", and deleting directories is the slow way to get it. Skip the cache at the call site instead:
# ignore cached results entirely for this run (local and remote)
npx nx run-many -t build --skip-nx-cache
# turn the remote cache off for this run; the local cache still works
npx nx run-many -t build --skip-remote-cache
# environment-variable form, useful in CI
NX_SKIP_NX_CACHE=true npx nx build my-app--disable-nx-cache and --disable-remote-cache are accepted aliases for the same two flags. Note the scope of each: --skip-nx-cache bypasses the cache completely for that run - nothing is read and nothing is written back, so the fresh result is not stored for anyone, including you. --skip-remote-cache turns the remote cache off for both reads and writes while the local cache keeps working normally, which makes it the right switch for working offline or ruling the network out while debugging.
Disabling caching for a target
If a task should never be cached - deploys, publishes, migrations, anything with side effects or non-deterministic output - clearing and skipping are the wrong tools. Turn caching off for that target in configuration:
// nx.json - one target, every project
{
"targetDefaults": {
"deploy": { "cache": false }
}
}The same cache: false works in a single project's project.json when only one project misbehaves.
Why clearing does not affect your team or CI
Everything above operates on one machine. If your workspace shares results through a remote cache, nx reset does not touch it: the next run simply restores the same outputs over the network, which is usually what you want and occasionally very confusing when you were trying to force a rebuild. That is what the skip flags are for. And if a remote entry genuinely needs to be gone - a poisoned or stale artifact - no CLI flag does it: entries are stored per input-hash and a well-behaved cache keeps them immutable, so the fix is server-side eviction. With Cachely that is a workspace-level operation in the dashboard. Our Nx remote cache guide covers how the remote layer fits together, including read-only tokens so pull requests can consume the cache without being able to write to it.
When clearing the cache is the wrong fix
Recurring cache trouble is nearly always a configuration problem wearing a disguise. Three patterns account for most of it:
- You clear the cache on a schedule because results go stale. Stale results mean a file that affects the output is missing from the task's
inputs, so its changes never invalidate the hash. Find it and declare it - the cache is doing exactly what the configuration says. - Hits restore nothing. A task with undeclared
outputscaches the terminal output but not the artifact, so a "hit" leavesdist/empty. Declare every output path the task produces. - Misses you cannot explain. Something volatile - a timestamp, an absolute path, an environment variable - is feeding the hash. Audit the target's
inputs(and its dependencies' inputs, vianpx nx graph) for over-broad patterns and missing exclusions rather than clearing anything.
All three are inputs-and-outputs problems, and tuning them is the highest-leverage cache work in an Nx workspace. The full walkthrough is in Tuning Nx cache configuration: inputs, outputs, and named inputs.
Quick reference
nx reset- clear local cache, workspace data, and stop the daemon; add--only-cache,--only-workspace-data, or--only-daemonto scope it..nx/cache- where the local cache lives; deleting it equals--only-cache.--skip-nx-cache- force execution for one run; the cache is neither read nor written.--skip-remote-cache- remote off (reads and writes), local cache unaffected.cache: false- permanently exclude a target that should never be cached.- None of these touch a shared remote cache - evict server-side if an entry must truly disappear.