Describe the bug
each time starting copilot cli, it will prompt access to current folder -
Copilot may read files in this folder. Reading untrusted files may lead Copilot to behave in unexpected ways. With your permission, Copilot may execute code or bash commands in this folder. Executing untrusted code is unsafe.
Do you trust the files in this folder?
I select yes to allow access in current folder. I do not expect copilot to try to violate this by accessing anything outside current folder.
often when performing a task, copilot cli may want to create temporary folders or files, and more often than not, it will try to use system /tmp folder to do this. this is not expected, as mentioned earlier, and will trigger another confirmation prompt if copilot may access /tmp. this additional prompt creates a block in the workflow where I need to deny access and explain that any temporary files/folders can be created inside current folder instead.
despite denying access once, github cli may still trigger actions that tries to use /tmp, and I will need to again deny and repeat instructions. this can happen multiple times during the same session.
it can be argued that using /tmp is perfectly safe, but I still want to restrict access to only the current folder, and if /tmp is considered safe and used in a normal way like any other program will use /tmp, then access should instead always be automatically allowed at program level instead of having github cli constantly ask for access. any access to /tmp, whether automatic or manual, should probably also be sandboxed to a unique session folder inside /tmp, but I frequently see github cli trying to write directly to /tmp/script.sh or output to /tmp/result.txt, etc.
I don't know what may or may not exist in my local /tmp folder from other programs that may write safe or unsafe information that would not be expected to be exposed to an llm and theoretically to the internet through an llm.
Affected version
GitHub Copilot CLI 1.0.36
Steps to reproduce the behavior
I don't have exact steps, but any task that is more complex, like analyzing/reviewing a code file in general or something like asking to find dead code in a file, etc., will often lead to github cli trying to create scripts and piping output to complete the task, and often try to use /tmp for this.
Expected behavior
never try to access anything outside what has been approved, especially not repeated attempts after already explicitly denying.
Additional context
macos on apple silicon
using tmux in zsh in alacritty
Describe the bug
each time starting copilot cli, it will prompt access to current folder -
I select yes to allow access in current folder. I do not expect copilot to try to violate this by accessing anything outside current folder.
often when performing a task, copilot cli may want to create temporary folders or files, and more often than not, it will try to use system /tmp folder to do this. this is not expected, as mentioned earlier, and will trigger another confirmation prompt if copilot may access /tmp. this additional prompt creates a block in the workflow where I need to deny access and explain that any temporary files/folders can be created inside current folder instead.
despite denying access once, github cli may still trigger actions that tries to use /tmp, and I will need to again deny and repeat instructions. this can happen multiple times during the same session.
it can be argued that using /tmp is perfectly safe, but I still want to restrict access to only the current folder, and if /tmp is considered safe and used in a normal way like any other program will use /tmp, then access should instead always be automatically allowed at program level instead of having github cli constantly ask for access. any access to /tmp, whether automatic or manual, should probably also be sandboxed to a unique session folder inside /tmp, but I frequently see github cli trying to write directly to /tmp/script.sh or output to /tmp/result.txt, etc.
I don't know what may or may not exist in my local /tmp folder from other programs that may write safe or unsafe information that would not be expected to be exposed to an llm and theoretically to the internet through an llm.
Affected version
GitHub Copilot CLI 1.0.36
Steps to reproduce the behavior
I don't have exact steps, but any task that is more complex, like analyzing/reviewing a code file in general or something like asking to find dead code in a file, etc., will often lead to github cli trying to create scripts and piping output to complete the task, and often try to use /tmp for this.
Expected behavior
never try to access anything outside what has been approved, especially not repeated attempts after already explicitly denying.
Additional context
macos on apple silicon
using tmux in zsh in alacritty