Gradle --rerun-tasks forces execution without clearing prior task outputs

Direct answer

No. Passing --rerun-tasks forces Gradle to execute a task action even when its inputs are unchanged, but it does not delete or clean the task's declared output directories beforehand. Any files left from a previous run remain in place unless the task implementation explicitly removes them.

Confirmed behavior (Gradle 8.x)

• --rerun-tasks is equivalent to setting Task.outputs.upToDateWhen { false } for that invocation. It bypasses the up-to-date check and the build-cache lookup, but it performs no filesystem cleanup.
• After a forced run, all files present in @OutputDirectory or @OutputFiles locations are captured as that task's outputs. Stale files from earlier executions are therefore stored in the build cache and will be restored on subsequent cache hits.
• The Gradle daemon retains workspace state across builds; stale outputs persist across daemon reuse unless explicitly cleaned.

Why this matters

Tasks that append to fixed locations (log aggregators, manifest mergers, custom generators) or that write to a directory without first clearing it will accumulate duplicate or obsolete files on repeated --rerun-tasks invocations. Those stale files end up in published artifacts (JARs, ZIPs, Docker layers) and pollute the build cache for every machine that restores that cache entry.

Safe patterns to avoid stale outputs

1. Delete the output directory at task start (preferred for ad-hoc tasks):

   @TaskAction
   void generate() {
       project.delete(outputDir)
       outputDir.mkdirs()
       // write fresh files
   }

2. Run clean before forced reruns when you control the invocation:

   ./gradlew clean myTask --rerun-tasks

3. Declare precise @OutputFiles instead of whole directories when the task produces a known, fixed set of files. Gradle then tracks only those files.
4. Write to a temporary directory and move atomically for tasks that must append or merge; this guarantees the target directory contains exactly the current run's output.

Verification you can run locally

1. Create a minimal project with a task that declares @OutputDirectory 'build/out' and writes a timestamped file in @TaskAction without deleting the directory first.
2. Run the task twice with --rerun-tasks and list build/out; you will see both timestamped files.
3. Run ./gradlew clean, then the task once, then again with --rerun-tasks; only one file appears, confirming clean removes prior outputs.
4. Optional: enable a build scan (--scan) or inspect ~/.gradle/caches to see the captured output files after a --rerun-tasks run that left stale files.

One diagnostic detail that could change the recommendation

Does your task use incremental task inputs (@InputChanges)? --rerun-tasks bypasses incremental analysis entirely, so the task receives no change information and must handle a full rebuild itself. If the task relies on incremental deltas to decide what to delete, it will not work under --rerun-tasks.