[richardsolomou]

Problem

Archiving (or suspending) a worktree that contained a Go module cache failed with EACCES: permission denied, rmdir '.../posthog/.flox/cache/go/pkg/mod/<pkg>/...'. Go's modcache marks every cached directory 0555, so fs.rm cannot unlink entries from those parents. The error propagated up archiveTask, the rollback chain undid the archive row, and the task reappeared in the sidebar — so to the user the archive button just... did nothing.

.flox/ exists in every flox-using worktree (even fresh ones, once anything is run), so this hit any task created in a flox-managed repo. Reported in Slack with multiple users blocked — "honestly kinda unusable".

Changes

• Added forceRemove(path) in packages/git/src/utils.ts. Tries fs.rm once with retries; on EACCES/EPERM, walks the tree restoring write bits (dirs 0o700, files 0o600) and retries. Symlinks are skipped via lstat so we don't chmod through them.
• Routed every worktree-deletion call site through forceRemove:
  • packages/git/src/worktree.ts — fallback when git worktree remove --force itself fails (it hits the same EACCES on the modcache and triggers the fallback path).
  • packages/git/src/sagas/worktree.ts — three rollback / execute spots in CreateWorktreeSaga, CreateWorktreeForBranchSaga, DeleteWorktreeSaga.
  • apps/code/src/main/services/archive/service.ts — parent-dir cleanup after deleteWorktree (both archive and rollback paths).
  • apps/code/src/main/services/suspension/service.ts — same pattern in deleteWorktreeOnDisk.

How did you test this?

• New unit test packages/git/src/utils.test.ts reproduces the bug: builds a directory tree shaped like a Go modcache (yaml.v3@v3.0.1/.github/...) with parent dirs at 0555, asserts plain fs.rm rejects with EACCES, then asserts forceRemove succeeds. Also covers the empty-tree and missing-path cases.
• Updated the suspension service test mock to expose the named exports of node:fs/promises that forceRemove needs (lstat, chmod, readdir).
• pnpm --filter code test — 1007/1007 pass.
• pnpm --filter code typecheck — clean.
• pnpm --filter @posthog/git typecheck — clean.
• pnpm format / pnpm lint — clean.

Publish to changelog?

no

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
packages/git/src/utils.test.ts:28-67
**Prefer parameterised tests**

The project style guide asks for parameterised tests. The three `it` blocks ("removes a writable tree", "is a no-op for a missing path", and "removes a tree with read-only directories") share the same arrange-act-assert shape and could be expressed as a single `it.each` table, eliminating the repeated `workDir` / `forceRemove` / `fileExists` boilerplate.

### Issue 2 of 2
packages/git/src/utils.test.ts:19-26
**`afterEach` cleanup doesn't handle read-only subdirectories**

If `forceRemove` throws mid-way through the read-only test (leaving `yaml.v3@v3.0.1` still present with mode `0555`), `afterEach` does `chmod(workDir, 0o700)` — but only on `workDir` itself, not on its nested read-only children. The subsequent `rm(workDir, { recursive: true, force: true })` would then fail with `EACCES`, and the error is silently swallowed by `.catch(() => {})`, leaving a temp directory behind. Using `forceRemove` here instead closes the gap:

```suggestion
  afterEach(async () => {
    if (workDir) {
      await forceRemove(workDir).catch(() => {});
      workDir = undefined;
    }
  });
```

_{Reviews (1): Last reviewed commit: "fix(code): chmod read-only subtrees befo..." | Re-trigger Greptile}