How to clear the Turborepo cache: --force, .turbo/cache, and --cache

There is no turbo cache clean, no turbo clean, and no clear-cache subcommand at all - searches for one land on flags and a directory instead. That is not an omission so much as a design choice: in Turborepo you either force re-execution past stale entries with --force, scope what the run may read and write with --cache, or delete the cache directory itself. Here is when each one is the right tool, plus the debugging flags that tell you why a task hit or missed in the first place.

`--force`: the answer to most "clear the cache" intents

The usual reason to clear a cache is a suspicion: an entry is stale or wrong, and you want to prove the task really executes. --force does exactly that without deleting anything - it ignores existing artifacts, re-executes every task in the run, and overwrites your local entries with the fresh results:

npx turbo run build --force            # ignore hits, re-execute, rewrite local entries
TURBO_FORCE=true npx turbo run build   # same thing via env, handy in CI

One caveat before treating --force as a shared-cache repair tool: what the re-upload does to a remote entry depends on the server. A content-addressed, immutable cache - which is what Cachely runs, and what a cache should be for poisoning-safety reasons - keeps the first artifact stored under a hash, so a forced re-upload of the same hash does not replace it. Forcing proves your task executes and refreshes your local state; it is not a mechanism for rewriting what the rest of the team restores.

Where the local cache lives

Local artifacts land in .turbo/cache inside the repository. Deleting that directory is the closest thing Turborepo has to a cache clean, and relocating it is a flag or an environment variable away:

rm -rf .turbo/cache                            # empty the local cache
npx turbo run build --cache-dir=/tmp/turbo     # point it somewhere else
TURBO_CACHE_DIR=/tmp/turbo npx turbo run build # same, via env

One adjacent command trips people up: turbo prune has nothing to do with the cache. It generates a pruned subset of your monorepo for Docker builds. If you ran it expecting cache cleanup, nothing was cleared.

`--cache` replaced `--no-cache` and `--remote-only`

The flags most older guides teach are deprecated. Turborepo consolidated cache control into a single --cache flag that takes explicit read/write permissions per source, defaulting to local:rw,remote:rw. Omitting a source disables both reading and writing for it:

npx turbo run build --cache=local:rw           # local only; remote off
npx turbo run build --cache=remote:rw          # remote only (old --remote-only)
npx turbo run build --cache=local:r,remote:r   # read both, write neither
npx turbo run build --cache=                   # no caching at all (old --no-cache)

The read/write split earns its keep in CI: remote:r gives pull-request builds cache hits without letting untrusted code write artifacts that a protected branch might later restore. That is a security property, not a performance tweak - the reasoning is laid out in our post on cache poisoning and CVE-2025-36852.

Debugging: find out why it hit before clearing anything

Two flags answer "why did this hit (or miss)?" directly, which beats clearing the cache and hoping:

npx turbo run build --dry=json   # show each task's hash and inputs, run nothing
npx turbo run build --summarize  # write a run summary under .turbo/runs/

Unexpected hit after an edit - the edited file is not part of the task's inputs. Hashing covers the package's source-controlled files by default (configurable with inputs in turbo.json), so a file Git ignores is not an input.
Unexpected miss between machines - compare two --dry=json outputs to see which hash inputs differ: environment variables listed in env, lockfile drift, and task inputs are the usual suspects.
Hit restores nothing - the task's outputs in turbo.json do not cover what it writes, so there is nothing in the entry to restore. Declare every produced path.

The remote cache does not clear from your laptop

Every mechanism above is local. If your team shares a remote cache, rm -rf .turbo/cache does not touch it, and the next run simply restores the same outputs over the network. And because entries in an immutable cache are keyed by content hash, no client flag replaces one either: if an artifact must genuinely be gone - a secret leaked into a bundle, a poisoned entry - evict it on the server side. With Cachely that is a workspace-level operation in the dashboard, and read-only tokens keep pull requests from writing to the shared cache in the first place. How the remote layer works, including the three environment variables any conforming server needs, is covered in our Turborepo remote cache guide.

Quick reference

--force / TURBO_FORCE=true - re-execute and rewrite your local entries; immutable remote entries stay as stored.
rm -rf .turbo/cache - the only real "clean"; local machine only.
--cache=... - scoped read/write control; replaces the deprecated --no-cache and --remote-only.
--dry=json and --summarize - see hashes and inputs before reaching for any of the above.
turbo prune - not a cache command.