[BUG] Read tool auto-denies files under cursor file with no approval prompt project Skills become unloadable

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Read tool returns “Permission denied” for files under a workspace .cursor/
directory, with no approval prompt and no way to approve.

This makes project Agent Skills unusable. The skills catalog gives the agent the
absolute path to SKILL.md and instructs it to read that file to load the skill,
but every such read is denied, so the skill body can never be loaded.

Per Agent Security Reading files and
searching code don’t require approval." A silent read denial contradicts this.

Related to #145558 and #148910, but both of those cover Write/StrReplace. This is
the read side. It’s arguably worse, because Skills are read-only by design — there
is no write involved that a user could be expected to approve.

Steps to Reproduce

  1. In any workspace, create .cursor/skills/example-skill/SKILL.md with valid
    YAML frontmatter (name, description) and a short body.
  2. Make sure the file is NOT open in the editor.
  3. Ask the agent to read that file by absolute path, or ask it to use the skill.
  4. Result: Permission denied, with no approval prompt.
  5. Now open the same file in the editor and ask again. The read succeeds.

Expected Behavior

Reads under .cursor/** should succeed, or at minimum surface an approval prompt
instead of an auto-decline, consistent with the security docs. Grep/Glob should
either traverse .cursor/ or report that access was blocked.

Operating System

MacOS

Version Information

Current Cursor Version → 3.21.16

For AI issues: which model did you use?

any model raise this issue

For AI issues: add Request ID with privacy disabled

Request ID: d4286306-2bef-452e-8977-ad5a4efcf7b5

Additional Information

Evidence (single session, macOS)

Attempt Result
Read .cursor/skills/<name>/SKILL.md (file closed) Permission denied, no prompt
Read the same file while open + focused in the editor Succeeds, full contents returned
Read .cursor/rules/<name>.mdc Denied — even though Cursor injects that same rule into the agent’s context
Read a dotfile at repo root, e.g. .rspec (closed) Denied
Read a normal non-dot file at repo root Succeeds
Shell ls -a .cursor/ Succeeds
Shell head -n 8 .cursor/skills/*/SKILL.md Succeeds — full contents
Grep / Glob tools scoped inside .cursor/ 0 matches, silently
StrReplace on a file under .cursor/ “Write permission denied:” (matches #145558)

Same asymmetry reported in #145558: shell tools reach these files freely, while
first-party tools are blocked.

What I ruled out

  • No .cursorignore file exists in the workspace.
  • .gitignore has no .cursor entry, and the default ignore list does not
    include .cursor/ (Ignore File | Cursor Docs).
  • No user-facing setting appears to control this. Searching Settings found
    nothing; #145558 shows users requesting such a toggle, so I assume none exists.
  • permissions.json has no file-read allowlist at all — only mcpAllowlist,
    terminalAllowlist, and autoRun (permissions.json Reference | Cursor Docs).
    So there is no documented way for a user to grant this access.

Impact

  • Project skills under .cursor/skills/ cannot be loaded by the agent.
  • Subagents are hit hardest: they don’t inherit the user’s open editor, so the
    “keep the file open” workaround doesn’t apply to them at all. Any rule or
    workflow instructing a subagent to load a project skill fails.
  • Grep/Glob returning 0 matches rather than an access error is misleading — it
    looks like the files don’t exist.
  • The open-file workaround is per-read: closing the tab re-blocks it.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey @saleh_salem, thanks for the detailed report, and especially for the table of what works and what doesn’t. It helped us narrow down the issue quickly.

This isn’t a general rule about .cursor/ or dotfiles. It happens when a team admin has configured a repository allowlist in the dashboard. Right now, the agent’s file tools (Read, Grep, Glob, Write) treat any path inside a dot-prefixed folder or file (.cursor/..., .rspec, .github/...) as outside the allowed repository, even though the rest of the repo is allowed. The editor uses a different matcher, so when the file is already open, Read works. I’ve shared this with the team and we’re tracking it.

For now, here’s a workaround a team admin can apply. In the dashboard, open the allowed repository entry in the repository allowlist and add these patterns next to the existing **:

.*
.*/**
**/.*
**/.*/**

This explicitly allows dot-prefixed files and folders inside the already allowed repository, and nothing outside it. After saving, restart Cursor and try reading .cursor/skills/<name>/SKILL.md again with the file closed.

If you’re not an admin, you can send them a link to this thread. And if Read is still blocked after adding the patterns, reply with a fresh Request ID and I’ll take another look.

Hey, quick update on this issue. The fix for Read/Grep/Glob/Write rejecting files under .cursor/ and other dot-prefixed paths on repository allowlist commands is already done, and it’ll ship in one of the next Cursor releases.

After the update, project skills under .cursor/skills/ should load normally, with no extra allowlist patterns needed. If an admin already added them, you can leave them in place until the update, they won’t hurt anything.

Let me know if the issue still happens after updating, and I’ll take another look.

ok, thanks

@deanrie Please confirm with me once it’s released. I couldn’t find a page for bugs or a release log for the bugs.

Hey, we don’t have a separate page specifically for this issue, but all release changes are published in the changelog: What's New in Cursor — Latest Updates & Release Notes. You can track what went into each version there.

For this specific case, I’ll reply right here in the thread when the fix makes it into a release, so you don’t need to check the changelog separately. After updating, skills under .cursor/skills/ should load normally, without any extra allowlist patterns.

Let me know if the issue is still happening after the update.

any update?

Hey, quick update on the issue. The fix for Read/Grep/Glob/Write that was rejecting files under .cursor/ and other dot-prefixed paths for commands with a repository allowlist is now in a release. Version 3.23 is already available on stable.

Please update to the latest version via Help → Check for Updates or download it from the website, then try reading .cursor/skills/<name>/SKILL.md when the file is closed. Skills under .cursor/skills/ should load normally, with no extra allowlist patterns needed. If an admin already added patterns like .*, .*/**, etc., you can keep them, they won’t hurt.

If the issue still happens after updating, please send a new Request ID with Privacy Mode turned off, and I’ll take another look.