You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Enterprise policy to allow yolo in CLI sandbox #4783
Describe the feature or problem you'd like to solve
There should be a separate policy scope for cli sandboxes for yolo mode and other permission related enterprise policies
Proposed solution
Enterprise policies allow restrictive access for setting like yolo mode, and other folder/tool settings. These are generally used because of trust within an enterprise environment, where broad tool access could cause damage. The point of sandbox mode is to create a 'safe place' for developers to work agentically. Currently, when yolo mode is disabled by enterprise policy, it applies to both standard and sandbox mode. Ideally, enterprise policies should have a separate sandbox hierarchy where any policy which could make sense to configure more permissively would allow a separate setting.
@mikemwalsh can you clarify when enterprises would allow bypassing? So far most want to enforce sandbox; but I am curious to hear your experience and plans to better understand the best shape for the governance.
I am imagining a scenario where the sandbox policies are configured in a way that an enterprise would trust the sandbox only has access to the resources/systems that are safe for it to actively work on (or locked down and only working on local code for example), in which case allow-all-tools could be seen as a safe operation within the sandbox, but not outside of it.
So what I was looking for was a way to say you cannot have permissive options outside the local sandbox, but within it, you can. Currently the enterprise policy to disable allow-all-tools is one and done, if you disable it, you cannot get it back in the sandbox.
Consolidating the clarified conditional-YOLO request into github/copilot-agent-runtime#29572, which has the more detailed enforcement and fail-closed acceptance criteria. The existing github/copilot-agent-runtime#37521 references both reports. The broader policy-hierarchy suggestion has been preserved on the canonical issue; this closure does not claim that broader feature is implemented.
Activity
digitarald commentedon Sep 14, 2026
@mikemwalsh can you clarify when enterprises would allow bypassing? So far most want to enforce sandbox; but I am curious to hear your experience and plans to better understand the best shape for the governance.
mikemwalsh commentedon Sep 15, 2026
@digitarald
I am imagining a scenario where the sandbox policies are configured in a way that an enterprise would trust the sandbox only has access to the resources/systems that are safe for it to actively work on (or locked down and only working on local code for example), in which case allow-all-tools could be seen as a safe operation within the sandbox, but not outside of it.
Copilot documentation (https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools#permissive-options) states "Before you grant Copilot wide-ranging permissions with an allow-all option, consider using local sandboxing"
So what I was looking for was a way to say you cannot have permissive options outside the local sandbox, but within it, you can. Currently the enterprise policy to disable allow-all-tools is one and done, if you disable it, you cannot get it back in the sandbox.
caarlos0 commentedon Nov 13, 2026
Consolidating the clarified conditional-YOLO request into github/copilot-agent-runtime#29572, which has the more detailed enforcement and fail-closed acceptance criteria. The existing github/copilot-agent-runtime#37521 references both reports. The broader policy-hierarchy suggestion has been preserved on the canonical issue; this closure does not claim that broader feature is implemented.