Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Windows sandbox: first permission propagation in a large project can exceed other helpers' 60 s lock timeout

Closed
#176 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
typescript
Domain
desktop, security

Research direction

Start with the Windows permission and lock code in win.rs: inspect ensure_project_grant (lines 867-885), revoke_project (887-907), and PermissionLock::acquire (1149-1165), along with the measurements from #103. Determine how to avoid helpers timing out during propagation while preserving crash safety; done when the large-project scenario no longer causes lock-acquisition failures and the error message explains ongoing propagation.

Written by the indexing model from the issue text.

Description

bug platform: windows priority: medium severity: medium

Found in the 2026-10-07 code review (inferred from #103's measurements and the lock scopes; not reproduced).

Problem

ensure_project_grant (win.rs:867-885) spreads FILE_MODIFY across the whole project tree while holding the global Local\PatchSandboxPermissions mutex. PermissionLock::acquire (win.rs:1149-1165) waits only 60 s. Every helper start also takes that lock (recover_abandoned_runs), and so does revoke_project (win.rs:887-907). #103 measured 23.4 s per 100,000 files, so a project of roughly 260,000 files or more exceeds the timeout.

Scenario

  1. The agent starts npm run dev in the background in a large monorepo.
  2. The tool returns after 3 s while the helper is still propagating.
  3. The agent's next run_command fails after a minute with "cannot acquire sandbox permission lock".
  4. Closing the project during propagation makes all 5 revoke attempts fail, so the grant is kept.

Fix

Hold a per-project lock (a named mutex derived from the capability name) during propagation instead of the global one; the marker file already handles crash safety. Or wait without a limit while the lock holder is alive (WAIT_ABANDONED covers its death). Make the error message say that propagation is in progress.

Dominant language
TypeScript
Stars
2
Forks
2
Avg merge
5h 28m
Merged PRs (30d)
24

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from PierrunoYT/patch

All issues in PierrunoYT/patch

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.