What causes "error deleting result file: %v" in plandex-ai/plandex?

Check and fix filesystem permissions on the results directory (process user needs write/delete)

error deleting result file: %v

Error message

error deleting result file: %v

What it means

Inside DeletePendingResultsForPaths, when a result is pending and its path matches, the goroutine calls os.Remove on `<resultId>.json`. If the removal fails (permissions, file already gone, directory not writable), it reports 'error deleting result file: %v' and aborts the sweep.

Source

Thrown at app/server/db/result_helpers.go:887

			}

			var result PlanFileResult
			err = json.Unmarshal(bytes, &result)

			if err != nil {
				errCh <- fmt.Errorf("error unmarshalling result file: %v", err)
				return
			}

			// log.Printf("Checking pending result: %s", resultId)

			if result.ToApi().IsPending() && paths[result.Path] {
				log.Printf("Deleting pending result: %s", resultId)

				err = os.Remove(filepath.Join(resultsDir, resultId+".json"))

				if err != nil {
					errCh <- fmt.Errorf("error deleting result file: %v", err)
					return
				}
			}

			errCh <- nil
		}(resultId)
	}

	for i := 0; i < len(files); i++ {
		err := <-errCh
		if err != nil {
			return fmt.Errorf("error deleting pending results: %v", err)
		}
	}

	return nil
}

View on GitHub (pinned to e2d772072e)

Solutions

Check and fix filesystem permissions on the results directory (process user needs write/delete)
Treat os.IsNotExist(err) as success (file already deleted) instead of an error
Ensure only one process/worker deletes pending results at a time (lock or leader election)
Verify the volume is not read-only or full (df, mount) and remount/clean

Example fix

// before
err = os.Remove(filepath.Join(resultsDir, resultId+".json"))
if err != nil {
    errCh <- fmt.Errorf("error deleting result file: %v", err)
    return
}
// after
err = os.Remove(filepath.Join(resultsDir, resultId+".json"))
if err != nil && !os.IsNotExist(err) {
    errCh <- fmt.Errorf("error deleting result file: %v", err)
    return
}

Defensive patterns

Strategy: try-catch

Validate before calling

if info, err := os.Stat(resultsDir); err != nil || !info.IsDir() {
    return fmt.Errorf("results dir not accessible: %v", err)
}
// check writability
f, err := os.CreateTemp(resultsDir, ".wtest")
if err != nil {
    return fmt.Errorf("results dir not writable: %v", err)
}
f.Close(); os.Remove(f.Name())

Try / catch

err := DeletePendingResultsForPaths(orgId, planId, paths)
if err != nil && strings.Contains(err.Error(), "error deleting result file") {
    if errors.Is(err, os.ErrPermission) { /* fix perms or surface to admin */ }
    if errors.Is(err, os.ErrNotExist) { /* safe to ignore */ }
}

Prevention

Run the service with a user that owns or can write the data/results directories
Ignore os.ErrNotExist in delete paths — deleting an already-deleted file is success
Ensure single-writer semantics for the results directory (locks or one worker per plan)
Monitor disk space and mount flags on the data volume

When it happens

Trigger: os.Remove fails because the results directory is read-only, the process lacks write permission, the file was deleted between ReadDir and Remove (race with another worker), or the path is on a read-only/full filesystem.

Common situations: Container running as non-root user against files owned by root; two servers or replays racing on the same plan; disk full or mounted read-only after a crash; NFS/permissions issues in shared storage.

Related errors

AI-assisted analysis of plandex-ai/plandex@e2d772072e (2026-09-05). Data as JSON: /api/errors/ac1264daf538c8a8. Report an issue: GitHub.