When Read or CopyFromBox refuses paths outside your user profile

On a registered Windows PC, Grok Bot’s Read, CopyFromBox, and CopyToBox tools are limited to your user profile folder (C:\Users\<you>). Shell is not. Paths on other drives (D:\, E:\, …) and junctions or symlinks inside the profile that resolve outside it return outside the allowed local-exec root. Staff (deanrie, Sep 19, 2026) on forum thread — current product behavior since mid-September client updates (noticed on 0.53.0, still on 0.57.1).

Local execution policy (approve / always allow) is separate from this path root. Official overview: Work with Grok Bot — Your local computer is separate.

Copy a file from the Bot computer onto another drive

1. Ask the Bot to CopyFromBox into a folder under your home profile (for example C:\Users\<you>\Downloads or Documents).
2. Confirm the file landed there.
3. Ask the Bot to move or copy it with Shell to the project folder on the other drive, for example PowerShell Move-Item or Copy-Item.

Read or copy a file that already lives outside the profile

1. Skip Read / CopyToBox for that path.
2. Ask the Bot to use Shell on the registered machine instead — for example Get-Content to read text, or Copy-Item to pull the file into the profile (or straight to where you need it).
3. If you still need the Bot’s cloud box to hold a copy, CopyToBox from a path under C:\Users\<you> after the Shell step.

Pitfalls

• Do not invent a broader file-tool allowlist or a Settings toggle that expands the local-exec root — none is documented; staff are tracking either matching Shell’s reach or teaching bots to pick Shell first.
• A junction or symlink under the profile that points at another drive is still rejected — the check uses the real path.
• Shell can still read and write those same outside-profile paths when local execution is allowed; a failing Read/CopyFromBox is not proof the disk is broken.