Grok Bot can't read files on your D: drive: why it says "Path is outside the allowed local-exec root"

3 hours ago

9 min read

Grok Bot can't read files on your D: drive, outside the allowed local-exec root error explained. Data Studios original cover

Last verified: November 15, 2026

Grok Bot can work on your own computer through its desktop app, yet many users find that it refuses to open, read or copy a file the moment that file sits on a second drive such as D: or E:, or in a project folder outside their Windows user folder. The bot reports that the path "is outside the allowed local-exec root and was refused", even when local execution is set to allow everything and the same bot has just created a folder in that very place. The answer from Grok Bot staff on the official forum is consistent: the file tools only reach your user folder, while shell commands are not held to that boundary, so the fix today is to read and move those files through the shell or to copy them into your user folder first.

The behavior has been reported since September 2026 and staff confirmed it on Grok Bot 0.75.3 for Windows 10 and Windows 11; reports on version 0.79.3 followed in early November, and new forum threads were still being opened on November 12, 2026. Staff have described it as a current limitation of the local computer connection, said there is no setting to add other folders or drives, and given no timeline for a change. Users on macOS with external drives and on Linux have reported the same refusal, although staff answers so far cover the Windows case.

··········

THE GROK BOT "LOCAL-EXEC ROOT" MESSAGE AND WHERE IT APPEARS.

The refusal shows up in the bot's chat or in its tool log when a Bot tries to use one of its built-in file tools on your registered computer. The wording reported on the forum is the same across versions, with the refused path appended at the end, for example a project folder on D:. The term "local-exec root" refers to the top-level folder that the local execution feature treats as its allowed area; on Windows, staff have identified that area as your profile folder, C:\Users\ followed by your user name.

Grok Bot has two different ways of acting on your machine, and they are checked differently. The file tools read files and move them between the Bot's cloud computer (which the documentation calls the hosted computer) and your desktop, while the Shell tool runs commands on your desktop under the policy you choose in the app settings. The table below sums up what staff have said about each tool.

........

Grok Bot tool	What it does on your computer	Paths outside your user folder
Read	Opens a local file so the Bot can see its content	Refused with the local-exec root message
CopyToBox	Copies a local file up to the Bot's cloud computer	Refused with the local-exec root message
CopyFromBox	Copies a file from the cloud computer down to your machine	Refused with the local-exec root message
Shell	Runs a command on your desktop, such as PowerShell on Windows	Works, subject to your local execution policy

........

The error text people search for, exactly as reported:

Path is outside the allowed local-exec root and was refused

This mismatch explains the most confusing part of the problem. A Bot can create a folder on D: through Shell, report success, and then fail on the very next step when it tries to copy a file into that folder with CopyFromBox, because the second step uses a file tool with a narrower boundary.

··········

WHY GROK BOT REFUSES FILES OUTSIDE YOUR USER FOLDER.

In replies posted between September 19 and October 29, 2026, Grok Bot staff explained that on a registered machine the Read, CopyToBox and CopyFromBox tools are limited to your user folder, and that Shell is not. One staff member added that the check uses the real location of a file, so a shortcut-style link inside your profile that points to another drive is refused as well. Asked about the option that grants local execution access to all folders, staff said that this permission does not apply to the file tools yet and that the mismatch with Shell "shouldn't happen". A support agent reply quoted by one user on November 7 described the home-folder limit as by design, so the company's own answers differ on whether this is intended or a gap to be closed.

........

Cause	How to check	Fix
The file is on another drive (D:, E:, F:)	The refused path in the message starts with a drive letter other than C:	Ask the Bot to read it with Shell, or copy it into your user folder first
The file is on C: but outside your profile, for example C:\Projects	The path does not start with C:\Users\ followed by your user name	Same as above: Shell for reading, a copy inside your profile for transfers
A junction or symbolic link inside your profile points to another drive	The folder looks like it is in your profile, but its real target is elsewhere	Use the real path through Shell; links do not extend the allowed area
An external drive on macOS or a separate mount on Linux	The file lives on a volume outside your home folder	Reported by users, not yet answered by staff: copy the file into your home folder
The "all folders" grant, Always allow or admin rights were expected to lift the limit	The setting is on, yet Read and CopyToBox still fail while Shell works	None of these change the file tools today, per staff; use the Shell route
Local execution itself is off or capped by your organization	Settings → Computer → Your computer shows Never allow, or your admin has capped the policy	Shell will not run either; ask your admin, since the cap is a deliberate choice

........

The last row is the one teams should read first. The workaround that staff suggest depends on Shell, and Shell depends on the "Execution on this computer" policy. If you or your administrator have chosen Never allow, the Bot cannot use Shell on your desktop at all, and the documentation recommends Never allow unless a Bot has a specific reason to work on local files. In that situation the refusal of out-of-profile paths is the least of the restrictions, and the right step is a conversation with whoever manages the policy.

··········

FIXING THE GROK BOT FILE REFUSAL STEP BY STEP.

The steps below follow the workarounds that Grok Bot staff posted on the official forum. None of them widens the allowed area of the file tools; they route the work through the tool that already has access under your own policy.

1. Read the refused path in the message and confirm where the file really is. If it is inside C:\Users\ followed by your user name and still refused, look for a junction or symbolic link in the folder chain, because the check follows the real target.

2. Open Settings → Computer → Your computer in the Grok Bot desktop app and check the row "Execution on this computer". Older builds show it as "Execution on Local Computer" until the desktop appears in the list. It must be set to Ask every time or Always allow for Shell to run.

3. To let a Bot read a file on D: or E:, tell it in the chat to use Shell for paths outside your user folder instead of trying Read first. Staff suggested reading the file straight into the command output, such as with Get-Content in PowerShell, which avoids leaving temporary copies behind.

4. To send a file from D: to the Bot's cloud computer, have the Bot copy it into your user folder with Shell (Copy-Item in PowerShell), then run CopyToBox on the copy.

5. To bring a finished file from the cloud computer to D:, have the Bot use CopyFromBox into a folder inside your profile, then move it to its final place with Shell.

6. Delete the temporary copies in your profile folder when the task is finished. One user who switched all bots to the Shell route reported that leftover files accumulate there.

The commands below are illustrative PowerShell examples of steps 3 and 4, with placeholder paths; replace them with your own folders and approve each command on the approval card if your policy asks every time.

# Illustrative only: read a file on D: through Shell
Get-Content -Path "D:\Projects\report.txt"

# Illustrative only: copy a file into your user folder before CopyToBox
Copy-Item -Path "D:\Projects\report.txt" -Destination "$env:USERPROFILE\GrokBotTransfer\"

On Windows, the steps above match what staff described. On macOS and Linux, users have reported the same message for external drives and separate mounts, and the same principle applies: keep files that the file tools must handle inside your home folder, and use the shell commands of your system for anything outside it. Grok Bot staff have not posted platform-specific guidance for macOS or Linux, so treat those steps as reported by users.

A practical way to avoid repeating the instruction in every chat is to tell each Bot once that files outside your user folder must be read and copied with Shell. Staff described two directions the team was weighing: making the file tools reach the same places as Shell, or making the Bot aware of the boundary so that it picks Shell by itself.

··········

[[ADPLUS_300x250_1]]

WHAT DOES NOT HELP: SETTINGS GROK BOT USERS HAVE ALREADY TRIED.

Forum threads show many users spending time on permissions that have no effect on this boundary. The table collects the changes that were tested and the result reported for each.

........

Change tried	Result	Source
Local execution set to Always allow	File tools still refuse D: paths	Staff reply, October 19, 2026
Running Grok Bot with administrator rights	No change	Staff reply and several users
Installing Grok Bot on D: instead of C:	No change; install location is unrelated	Staff reply, October 19, 2026
Granting local execution access to all folders	Applies to Shell only, not to the file tools yet	Staff reply, October 26, 2026
Full Disk Access for Grok Bot on macOS	External drive still refused	One user report, November 7, 2026
Full Control on the folder, Controlled Folder Access off (Windows)	Still refused	One user report

........

Antivirus exclusions and Windows folder permissions are a separate topic. They can block local execution altogether, which other forum threads describe, but they do not produce the local-exec root message, which staff have described as unrelated to permissions or install location.

··········

DOCUMENTED BY THE COMPANY VS REPORTED BY GROK BOT USERS.

The Grok Bot documentation describes local execution in general terms. It says Bots can run commands, read files and move files between the cloud computer and the local machine through the desktop app, that per-command approval is the default, that members choose Ask every time, Always allow or Never allow, and that admins can cap the policy for the whole team with the "Execution on Local Computer" control, where a member's own setting still applies when it is stricter. As of November 15, 2026, none of the documentation pages checked for this page (security, approvals, troubleshooting, FAQ and computer pages) mentions the user-folder boundary of the file tools.

Everything specific about the boundary comes from staff replies on the official Grok Bot forum, which is hosted on the Cursor community site: the list of affected tools, the real-path check on links, the fact that the all-folders grant does not reach the file tools, the absence of a setting to add drives, and the Shell workarounds. The macOS and Linux cases, the leftover temporary files and the failed Full Disk Access test are reports from several independent users and have not been confirmed by the company.

··········

A DIFFERENT GROK BOT ERROR: "LOCAL TOOLS ARE TURNED OFF".

Some users meet a second refusal that looks related but has another cause. The Bot says that local tools are turned off and that the user has set local tool access to Never, even though the setting shows Always allow or Ask every time. The official troubleshooting page lists this message as a known issue on Cursor's side and states that the setting is correct and that restarting, reinstalling or changing the setting will not clear it. If you see that message, the steps above do not apply, because Shell is blocked too; the only documented answer is to wait for the fix.

··········

KEEPING GROK BOT LOCAL FILE WORK RELIABLE AFTER UPDATES.

Because the boundary is a current limitation that staff said the team is discussing, an update could change it without notice. After each Grok Bot update, a quick test tells you where you stand: ask a Bot to Read a small text file on D: and see whether the local-exec root message still appears. If Read succeeds, the file tools have been extended and the Shell detour is no longer needed.

Until then, project folders that Bots touch often are easier to manage inside your user folder, and the documentation's advice to keep local access disabled unless a task needs it still holds. Long Shell detours also mean more steps per task, which is relevant on accounts close to their quota; our report on Grok Bot usage limits and serving costs covers the plan side, and the earlier coverage of Grok Bot's enterprise access and organization-wide invites describes how organizations roll the Bot out to their members. Because the official Grok Bot forum is hosted on the Cursor community site, users often meet both products' errors in the same threads; our page on Cursor's "Connection failed" message covers the most common connection failure on that side.

··········

GROK BOT FILES ON D: AND OTHER DRIVES: THE STATE OF THE LIMIT.

The local-exec root message is Grok Bot's file tools refusing a path outside your user folder, and on Windows that means every file on a second drive and every folder on C: outside C:\Users\ followed by your name. Changing permissions, running as administrator or granting all-folder access does not lift it, because those settings govern Shell and Windows itself, and the file tools apply their own check. The working routes are the ones staff posted: read through Shell, and stage transfers through a folder inside your profile. Staff have acknowledged that Shell and the file tools should behave the same way, and as of November 15, 2026 there is still no setting, release note or date for a change.

··········

·····

DATA STUDIOS

·····

datastudios.org