macOS: Stuck in loop on TCC permission dialog for Documents folder — Allow does nothing or re-presents the dialog

[fbartho]

Describe the bug

Warp got stuck asking for permission to access my Documents folder. The macOS TCC dialog says:

"Warp" would like to access files in your Documents folder.

Clicking Allow either does nothing, or instantly re-presents the same permission dialog. The dialog cannot be dismissed by granting permission.

Possibly relevant: shortly before (or overlapping with) this dialog, Warp presented a request to access my Downloads folder, which I approved successfully. The Documents request may have raced with / overlapped the Downloads one.

To reproduce

1. Trigger Warp to access the Downloads folder (TCC prompt appears) and approve it.
2. Warp then (or concurrently) requests access to the Documents folder.
3. Click Allow on the Documents dialog.
4. Dialog re-appears immediately (or the click has no effect).

Expected behavior

Clicking Allow grants access and dismisses the dialog once.

Screenshots

Standard macOS folder-access permission dialog for Documents

Environment

• Warp version: v0.2026.07.01.09.21.stable_01
• OS: macOS 27.0 (build 26A5378j)
• Hardware: Apple Silicon Mac

[oz-for-oss]

@fbartho

Here's what I found while triaging this issue:

This appears to be a macOS protected-folder permission prompt loop, not a normal denied file read. I did not find an existing open duplicate with the same Documents prompt reappearing after Allow.

I have a few follow-up questions before I can narrow this down:

1. Can you attach the screenshot or a short screen recording showing the Documents prompt reappearing after you click Allow?
2. Which exact Warp action immediately triggers the Downloads → Documents prompts?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that macOS protected-folder TCC prompt for Documents appears to loop after Allow, likely tied to Warp local workspace/file access but missing the exact triggering action..

Triage summary

This looks like a macOS protected-folder permission bug: the reporter sees the Documents TCC prompt loop or ignore Allow after a nearby Downloads prompt on Warp v0.2026.07.01.09.21.stable_01 / macOS 27.0 (26A5378j), Apple Silicon.

Reproducibility: Medium. The dialog text and environment are specific, but the exact Warp action that starts folder access is not yet identified, and no screenshot/video or logs are attached.

Likely area: Local workspace/file access. The most relevant code paths are Project Explorer/global search and repo metadata indexing/watching: app/src/workspace/view/left_panel.rs wires active local directories into the Project Explorer/global search views; app/src/code/file_tree/view.rs registers and refreshes lazy-loaded directories; app/src/search/files/model.rs reads local folder contents; and crates/repo_metadata/src/local_model.rs, crates/repo_metadata/src/entry.rs, and crates/repo_metadata/src/watcher.rs perform directory traversal and watcher registration. These filesystem accesses can hit macOS protected folders such as Documents/Downloads. script/update_plist also currently adds several privacy usage strings but not Documents/Downloads folder usage descriptions, which is worth checking against the reporter's macOS build.

Duplicate check: I enumerated 3,787 open issues and 39 recently closed issues. I did not find two existing issues matching the same Documents TCC prompt loop, so this should not be marked duplicate yet.

Question reasoning

1. Can you attach the screenshot or a short screen recording showing the Documents prompt reappearing after you click Allow? — This is a visual macOS permission-dialog loop, and media would confirm the exact prompt wording, sequence, and whether the dialog is truly dismissed and re-presented.
2. Which exact Warp action immediately triggers the Downloads → Documents prompts? — The current report does not identify whether the trigger is Project Explorer, global search/file picker, an agent action, a command run from a protected folder, or another surface; that determines the owner and reproduction path.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[fbartho]

1. Screenshot has been attached to the Ticket description now, though I doubt it will be helpful for debugging the issue as it's very generic.
2. I was just running a normal daily workflow script within Claude Code within warp. Unfortunately, I can't tell you exactly what that did immediately prior to the dialog. It could have been coincidental that the dialog popped up. This warp application was running for about a week, so I had run that same workflow on several previous occasions, and it didn't fail to accomplish anything, so there were no issues to identify exactly what was accessed.

Please advise if more info is needed or if you can remove that label now.

[oz-for-oss]

@fbartho

Thanks for adding the screenshot and workflow context. This now looks sufficiently triaged as a macOS Files & Folders/TCC prompt issue, so I think needs-info can be removed.

The remaining uncertainty is not a generic screenshot gap; it is which terminal/Claude Code subprocess access caused macOS to request Documents immediately after Downloads. If this happens again, the most useful extra evidence would be the active command/process around the prompt or redacted Warp logs from that timestamp, but I would not block routing on that since the original trigger may not be reconstructable.

Reasoning

Reasoning for maintainers:

• This was triggered by an @oz-agent follow-up on an already-triaged issue asking whether the newly attached screenshot/context is enough, so response mode is appropriate and no labels are emitted by this artifact.
• Reporter evidence now includes the exact Warp version (v0.2026.07.01.09.21.stable_01), macOS build (27.0 / 26A5378j), Apple Silicon, a screenshot of the standard Documents folder TCC dialog, and follow-up context that the prompt happened while a normal workflow script was running inside Claude Code in Warp after the app had been open for about a week.
• Code inspection points away from a Workspace UI-only issue. Warp launches user shells through PTY spawning/terminal-server code (app/src/terminal/local_tty/spawner.rs, app/src/terminal/local_tty/server/mod.rs, app/src/terminal/local_tty/unix.rs), so filesystem access by a shell/CLI child process can be attributed by macOS to the Warp app in TCC prompts. app/src/terminal/local_tty/terminal_view_adaptor.rs also explicitly treats third-party CLI agents such as Claude Code as PTY-driven sessions.
• script/update_plist currently adds several privacy usage descriptions with wording like "A program in Warp wants ..." for AppleEvents, camera, microphone, contacts, calendars/reminders, location, and photos, but repository search found no NSDocumentsFolderUsageDescription or NSDownloadsFolderUsageDescription. Apple documentation says these keys are optional but recommended for explaining protected-folder access, and that first direct access to Documents/Downloads without implied user consent triggers a system prompt remembered in TCC. This may improve prompt wording but does not by itself explain the reported allow/re-present loop.
• Duplicate check: paginated all open issues via gh api --paginate, excluding PRs and macOS: Stuck in loop on TCC permission dialog for Documents folder — Allow does nothing or re-presents the dialog #13647. The strongest open neighbor is Operation not permitted error on Warp #8991 (Operation not permitted after macOS file permissions changed), but it reports shell EPERM/lost access rather than an Allow dialog loop. Recent closed issue icalBuddy fails with "error: No calendars.": Info.plist is missing NSRemindersUsageDescription, so macOS silently denies the Reminders prompt (works in Terminal.app) #13558 is TCC-related but about missing Calendar/Reminders usage descriptions and icalBuddy, not Documents/Downloads. Fewer than two likely duplicate candidates were found, so this should not be marked duplicate.
• Suggested maintainer label/routing if doing a separate label-changing pass: keep bug, triaged, repro:medium, and os:mac; consider area:shell-terminal and/or area:agent over area:workspace because the new context points to a Claude Code/terminal subprocess causing the protected-folder prompt. Removing needs-info is reasonable because the unresolved detail is the exact child access, which the reporter cannot reconstruct and should not block routing.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz