This operation accesses path(s) outside allowed directories: /i

[doggy8088]

Describe the bug

I'm on Windows. This command is not accessing folder /i. Please check the screenshot below:

The command curl.exe -s "https://developers.googleblog.com/en/on-device-genai-in-chrome-chromebook-plus-and-pixel-watch-with-litert-lm/" | findstr /i "title\|content\|description" is not accessing /i folder.

Affected version

0.0.327 Commit: 0cbec74

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response

[SteveSandersonMS]

Thanks for reporting this. The tricky thing here is that /i is actually a valid path even on Windows (yes really! create a directory called i at the root of your disk and the try dir "/i"), so we'd have to hardcode knowledge that findstr treats /i as a flag and not as a path.

If it turns out that findstr is a command that the agent commonly uses, we would want to bake that knowledge in. So, thanks for the suggestion.

[doggy8088]

@SteveSandersonMS This is another similar bug:

[hariseldon78]

i had a similar bug: it was creating a rust file and misinterpreted the comments indicators as paths:

[SteveSandersonMS]

@doggy8088 Thanks. I recognize that issue - definitely something we can fix.

@hariseldon78 Hmm, that's more surprising. I'm not sure why it would ever care if the contents of a file contain paths - it's only supposed to be concerned with the shell script. Is there any chance you know how to reproduce this issue? I don't think the unblurred script at the top of your screenshot would repro it.

[hariseldon78]

i am using it together with the spec-kit, following this guide: https://youtu.be/7tjmA_0pl2c?si=6fpvpSqbH3zQ37Vs ;
the error appeared as soon as i started the /implement phase.
Later on i got the same error but the // was inside a grep argument

[RyanHecht]

We've improved our path detection heuristic in 0.0.332, commenters should try it out and see if they still see this in their cases!

[doggy8088]

@RyanHecht I'm using 0.0.332. There is a new issue.

I have a text block that contains some code including a line comment. such as:

cat > BUNDLE_COURSE_FIX.md << 'EOF'
...
// line comment
...
EOF
cat BUNDLE_COURSE_FIX.md

[yanuoma]

I have a similar issue on Windows.

I have added paths like C:\users\abc\repos\code to allowed directories (shown in configs file). However, Copilot is still showing This operation accesses path(s) outside allowed directories for files in the subfolder of the allowed directory, like C:\users\abc\repos\code\package.json, when Copilot is trying to execute Get-Content PowerShell command with that path.

[SteveSandersonMS]

@yanuoma Is it possible you're running an older version of Copilot? We fixed a bug in that area (specifically: prompting about paths you've already approved) about a week ago. If you're still seeing it, can you paste in the version of Copilot you're using and the shell script it's prompting you to confirm?

[doggy8088]

I tried this prompt in v0.0.338 on Windows 10 (pwsh.exe):

Run this command and summary it: curl.exe -s "https://academy.openai.com/public/tags/prompt-packs-6849a0f98c613939acef841c"; $html -replace '<[^>]+>', ' ' -replace '\s+', ' ' | Select-String -Pattern "Prompt Pack|ready-to-use|IT Staff|Sales|Marketing|Engineer|Product|Executive|Customer Success" -Context 5,5 | Select-Object -First 20

It still treat \s+ as a path.

[SteveSandersonMS]

Thanks @doggy8088. That's not the same thing that @yanuoma is reporting, since they are talking about things that actually are paths (in their example, C:\users\abc\repos\code\package.json), and that should be fixed now.

Your issue is about things we shouldn't be treating as paths (\s+), and that is not fixed.

[yanuoma]

I seem to not see this recently, so it might be fixed, and I was using an old version. I will post it here if it repro again