Problem
Copilot SDK workflows need an opt-in, shell-free "native repository profile" that disables Bash, write_bash, generic task tools, and CLI proxy, exposing only a fixed go_repository operation set (status/diff/prepare_branch/format/readiness/validate/commit) bound to a clean GITHUB_SHA, so downstream users aren't forced to maintain a fork just to get a closed, credential-free Git/Go validation lifecycle.
Context
Reported upstream: github/gh-aw#61629, with a working reference implementation in jpmicrosoft/gh-aw forks (PRs #1, #2, #5) and passing fork CI.
Root Cause
Upstream currently has no versioned tool profile that jointly disables Bash/write_bash/task/cli-proxy while allowlisting a single bounded native tool; the AWF sandbox has no first-class way to advertise/enforce such a restricted profile beyond ad hoc --allow-domains/capability flags.
Proposed Solution
Track upstream go-repository tool-profile work and, on the AWF side, define what sandbox guarantees such a profile needs (e.g. cli-proxy fully disabled, no arbitrary exec, bounded working directory) so AWF can validate/enforce the profile's constraints rather than trusting the engine alone. Coordinate with the upstream maintainers' "engine-independent slice first" plan noted in the issue thread.
Generated by Firewall Issue Dispatcher · copilot · auto · 26 AIC · ⊞ 9.2K · ◷
Problem
Copilot SDK workflows need an opt-in, shell-free "native repository profile" that disables Bash,
write_bash, generic task tools, and CLI proxy, exposing only a fixedgo_repositoryoperation set (status/diff/prepare_branch/format/readiness/validate/commit) bound to a cleanGITHUB_SHA, so downstream users aren't forced to maintain a fork just to get a closed, credential-free Git/Go validation lifecycle.Context
Reported upstream: github/gh-aw#61629, with a working reference implementation in jpmicrosoft/gh-aw forks (PRs #1, #2, #5) and passing fork CI.
Root Cause
Upstream currently has no versioned tool profile that jointly disables Bash/
write_bash/task/cli-proxy while allowlisting a single bounded native tool; the AWF sandbox has no first-class way to advertise/enforce such a restricted profile beyond ad hoc--allow-domains/capability flags.Proposed Solution
Track upstream
go-repositorytool-profile work and, on the AWF side, define what sandbox guarantees such a profile needs (e.g. cli-proxy fully disabled, no arbitrary exec, bounded working directory) so AWF can validate/enforce the profile's constraints rather than trusting the engine alone. Coordinate with the upstream maintainers' "engine-independent slice first" plan noted in the issue thread.