[aw] PR Code Quality Reviewer is missing required tool

[github-actions]

Workflow Failure

Workflow: PR Code Quality Reviewer
Branch: copilot/aw-failures-fix-read-tool-permission-scoping
Run: https://github.com/github/gh-aw/actions/runs/30765615691
Pull Request: #49840

Warning

Repeated Permission Denied: The agent was denied permission to run 1 command(s) and stopped retrying.

Denied Commands:

• | ... and 1 more

How to fix this

The agent ran in non-interactive mode (--no-ask-user) and could not request permission at runtime.

To resolve repeated permission denied errors, update the workflow prompt to avoid these commands or use approved alternatives. Use the following prompt with any coding agent:

The agentic workflow pr-code-quality-reviewer encountered repeated permission denied errors for these commands:
`| ... and 1 more`

Please update the workflow prompt so the agent:
1. Uses built-in tools (GitHub API, file read/write) instead of the denied shell commands
2. Or achieves the same goal through alternative approaches that do not require shell permission

Warning

Engine Failure: The copilot engine terminated unexpectedly.

Last agent output:

{"type":"tool.execution_complete","timestamp":"2026-08-02T20:30:41.294Z","data":{"toolName":"bash","mcpServerName":"","success":true,"result":{"content":"---\nname: checkout-credential-review\ndescription: Review code that performs git or gh operations against repository checkouts in gh-aw, checking that the right credentials are available at the right time and that sparseness, shallowness and credential-free factors are properly considered.\n---\n\n# Checkout Credential Review\n\nUse this skill when reviewing or writing code in `pkg/workflow/`, `actions/setup/js/`, or compiled `.lock.yml` workflows that runs `git`, `gh`, or any other remote-touching operation against a repository checkout.\n\n## Background\n\nEach entry in a workflow's `checkout:` block may declare its own credentials (`github-token:`, `github-app:`), and the compiler wires those into the corresponding `actions/checkout` step ([pkg/workflow/checkout_step_generator.go](pkg/workflow/checkout_step_generator.go)). Generated checkouts always set `persist-credentials: false`, so the on-disk repo retains **no** credentials after the step finishes — only `actions/checkout`'s own internal token is used during the clone, and it is scrubbed in its post-step.\n\nA separate step that wants to authenticate later must either (a) re-inject a token at command level (e.g. `git -c http.extraheader=...`) or (b) be passed the per-checkout token via env. The compiler does *not* automatically thread per-checkout `github-token`s into downstream steps.\n\nTwo important contexts deliberately run with **no git credentials**:\n\n- The **safe-outputs MCP server** and its handlers (`generate_git_bundle.cjs`, `generate_git_patch.cjs`, `create_pull_request.cjs`). Errors in these paths explicitly say \"the safe-outputs MCP server has no credentials for private repositories\" — fetch/push will fail for private repos.\n- The **agent runtime** after `actions/checkout`. The agent prompt in [actions/setup/md/safe_outputs_push_to_pr_branch.md](actions/setup/md/safe_outputs_push_to_pr_branch.md) explicitly tells the model not to attempt `git fetch`, `git pull`, `git push`, or any other authenticated git operation, and to report unavailable branches rather than try to fetch them.\n\n## Review checklist\n\nWhen you see a new `git`, `gh`, `execFileSync('git'…)`, or compiled `run:` block:\n\n1. **Does it touch a remote?** Local-only commands (`symbolic-ref`, `rev-parse`, `log`, `show`, `merge-base`, `diff`, `status`) need no credentials. Anything in `fetch | pull | push | clone | ls-remote | remote (set-url|add|update)` does, plus on-demand blob fetches in partial clones.\n2. **Which checkout is it operating on?** If it's a cross-repo entry from `checkout:`, the relevant credential is *that entry's* `github-token`, not the workflow's default `GITHUB_TOKEN`. Confirm the per-entry token is actually threaded into the step's env (or refuse to do remote operations and degrade gracefully).\n3. **Which job/context emits it?** Agent job and safe-outputs MCP server both run without git credentials by design. Any remote git operation there must be wrapped in `try/catch`, fail soft, and surface a clear \"no credentials\" error rather than a raw git stderr.\n4. **Sparse / shallow / monorepo concerns.** Avoid emitting steps that deepen (`git fetch --unshallow`, `--deepen=N`) or widen (`git fetch origin '+refs/heads/*'`) a sparse or shallow checkout of a large monorepo — these need credentials *and* can pull hundreds of MB. Prefer expanding `fetch:` / `fetch-depth:` / `sparse-checkout:` at compile time so it happens during `actions/checkout` with its internal token, never later.\n5. **`gh` is REST, not git.** `gh api …` uses whatever `GH_TOKEN` is in the step's env — it does **not** automatically inherit per-checkout PATs. For cross-org private repos, either thread the right token in or accept the call will 404 and handle it.\n\n## Related\n\n- [docs/src/content/docs/reference/checkout.md](docs/src/content/docs/reference/checkout.md) — \"Git Credentials After Checkout\"\n- [docs/sparseness.md](docs/sparseness.md) — sparse/blobless credential lifecycle\n- [pkg/workflow/checkout_step_generator.go](pkg/workflow/checkout_step_generator.go) — token wiring per checkout\n- [actions/setup/md/safe_outputs_push_to_pr_branch.md](actions/setup/md/safe_outputs_push_to_pr_branch.md) — agent-facing guidance\n<shellId: 9 completed with exit code 0>","detailedContent":"---\nname: checkout-credential-review\ndescription: Review code that performs git or gh operations against repository checkouts in gh-aw, checking that the right credentials are available at the right time and that sparseness, shallowness and credential-free factors are properly considered.\n---\n\n# Checkout Credential Review\n\nUse this skill when reviewing or writing code in `pkg/workflow/`, `actions/setup/js/`, or compiled `.lock.yml` workflows that runs `git`, `gh`, or any other remote-touching operation against a repository checkout.\n\n## Background\n\nEach entry in a workflow's `checkout:` block may declare its own credentials (`github-token:`, `github-app:`), and the compiler wires those into the corresponding `actions/checkout` step ([pkg/workflow/checkout_step_generator.go](pkg/workflow/checkout_step_generator.go)). Generated checkouts always set `persist-credentials: false`, so the on-disk repo retains **no** credentials after the step finishes — only `actions/checkout`'s own internal token is used during the clone, and it is scrubbed in its post-step.\n\nA separate step that wants to authenticate later must either (a) re-inject a token at command level (e.g. `git -c http.extraheader=...`) or (b) be passed the per-checkout token via env. The compiler does *not* automatically thread per-checkout `github-token`s into downstream steps.\n\nTwo important contexts deliberately run with **no git credentials**:\n\n- The **safe-outputs MCP server** and its handlers (`generate_git_bundle.cjs`, `generate_git_patch.cjs`, `create_pull_request.cjs`). Errors in these paths explicitly say \"the safe-outputs MCP server has no credentials for private repositories\" — fetch/push will fail for private repos.\n- The **agent runtime** after `actions/checkout`. The agent prompt in [actions/setup/md/safe_outputs_push_to_pr_branch.md](actions/setup/md/safe_outputs_push_to_pr_branch.md) explicitly tells the model not to attempt `git fetch`, `git pull`, `git push`, or any other authenticated git operation, and to report unavailable branches rather than try to fetch them.\n\n## Review checklist\n\nWhen you see a new `git`, `gh`, `execFileSync('git'…)`, or compiled `run:` block:\n\n1. **Does it touch a remote?** Local-only commands (`symbolic-ref`, `rev-parse`, `log`, `show`, `merge-base`, `diff`, `status`) need no credentials. Anything in `fetch | pull | push | clone | ls-remote | remote (set-url|add|update)` does, plus on-demand blob fetches in partial clones.\n2. **Which checkout is it operating on?** If it's a cross-repo entry from `checkout:`, the relevant credential is *that entry's* `github-token`, not the workflow's default `GITHUB_TOKEN`. Confirm the per-entry token is actually threaded into the step's env (or refuse to do remote operations and degrade gracefully).\n3. **Which job/context emits it?** Agent job and safe-outputs MCP server both run without git credentials by design. Any remote git operation there must be wrapped in `try/catch`, fail soft, and surface a clear \"no credentials\" error rather than a raw git stderr.\n4. **Sparse / shallow / monorepo concerns.** Avoid emitting steps that deepen (`git fetch --unshallow`, `--deepen=N`) or widen (`git fetch origin '+refs/heads/*'`) a sparse or shallow checkout of a large monorepo — these need credentials *and* can pull hundreds of MB. Prefer expanding `fetch:` / `fetch-depth:` / `sparse-checkout:` at compile time so it happens during `actions/checkout` with its internal token, never later.\n5. **`gh` is REST, not git.** `gh api …` uses whatever `GH_TOKEN` is in the step's env — it does **not** automatically inherit per-checkout PATs. For cross-org private repos, either thread the right token in or accept the call will 404 and handle it.\n\n## Related\n\n- [docs/src/content/docs/reference/checkout.md](docs/src/content/docs/reference/checkout.md) — \"Git Credentials After Checkout\"\n- [docs/sparseness.md](docs/sparseness.md) — sparse/blobless credential lifecycle\n- [pkg/workflow/checkout_step_generator.go](pkg/workflow/checkout_step_generator.go) — token wiring per checkout\n- [actions/setup/md/safe_outputs_push_to_pr_branch.md](actions/setup/md/safe_outputs_push_to_pr_branch.md) — agent-facing guidance\n<shellId: 9 completed with exit code 0>"}}}
{"type":"assistant.message","timestamp":"2026-08-02T20:30:59.644Z","data":{"content":""}}
{"type":"tool.execution_start","timestamp":"2026-08-02T20:30:59.647Z","data":{"toolName":"bash","mcpServerName":"","command":"grep -n \"cat pkg\\|isReadPathAllowedByShellRules\\|matchesGlob\\|relativeRequestedPath\" /home/runner/work/gh-aw/gh-aw/actions/setup/js/copilot_sdk_driver.test.cjs | head -30"}}
{"type":"tool.execution_complete","timestamp":"2026-08-02T20:30:59.713Z","data":{"toolName":"bash","mcpServerName":"","success":true,"result":{"content":"1175:      // the workflow only grants shell(cat pkg/**/*.go) (a relative glob pattern).\n1198:            allowedTools: [\"shell(cat pkg/**/*.go)\", \"shell(grep)\", \"shell(wc)\"],\n<shellId: 10 completed with exit code 0>","detailedContent":"1175:      // the workflow only grants shell(cat pkg/**/*.go) (a relative glob pattern).\n1198:            allowedTools: [\"shell(cat pkg/**/*.go)\", \"shell(grep)\", \"shell(wc)\"],\n<shellId: 10 completed with exit code 0>"}}}
{"type":"assistant.message","timestamp":"2026-08-02T20:31:33.356Z","data":{"content":""}}
{"type":"tool.execution_start","timestamp":"2026-08-02T20:31:33.359Z","data":{"toolName":"task","mcpServerName":""}}
{"type":"subagent.started","timestamp":"2026-08-02T20:31:33.395Z","data":{"agentName":"general-purpose","agentDisplayName":"General Purpose Agent","toolCallId":"toolu_01Pqxr7HvCSmYC83qDP4teFs"}}
{"type":"tool.execution_complete","timestamp":"2026-08-02T20:31:33.404Z","data":{"toolName":"task","mcpServerName":"","success":true,"result":{"content":"Agent started in background with agent_id: grumpy-coder. You'll be notified when it completes. Tell the user you're waiting and end your response, or continue unrelated work until notified. The agent supports multi-turn conversations — use write_agent to send follow-up messages.","detailedContent":"Prompt to general-purpose agent (grumpy-coder):\nYou are a extremely critical, grumpy senior code reviewer doing first-pass issue mining on a PR diff in the github/gh-aw repository. Do NOT be nice. Find every correctness, security, performance, and maintainability issue you can, but ONLY within the changed lines shown below (do not comment on unchanged code).\n\nPR: \"Fix read-tool workspace permission scoping regression (daily workflows killed by denial threshold)\" (#49840)\nFiles changed: actions/setup/js/copilot_sdk_driver.test.cjs (test only), actions/setup/js/copilot_sdk_permissions.cjs (source change).\n\nContext: `buildCopilotSDKPermissionHandler` in copilot_sdk_permissions.cjs decides whether the Copilot SDK approves file-read requests during an agentic workflow run, based on the workflow's configured `allowedTools` (from frontmatter). The fix adds an early-return in the `case \"read\":` branch of `isAllowed(request)`: if `logOptions.workspaceRoot` (== process.env.GITHUB_WORKSPACE) is set and the requested path is at/under that root (via string prefix match after `normalizePermissionPath`), the read is approved UNCONDITIONALLY — bypassing the existing `hasReadGrant || allowedToolEntries.has(\"shell\") || isReadPathAllowedByShellRules(...)` checks entirely for anything inside the workspace.\n\nDiff (source file only, most important part):\n```\n      case \"read\":\n        // Any read grant (read, read(...), read:*) is path-agnostic in Copilot SDK.\n+       // Always allow reads for paths at or under the workspace root (GITHUB_WORKSPACE).\n+       // Every workflow runs inside its own checkout and must be able to read its source tree\n+       // regardless of any narrower tool-permission scoping configured elsewhere.\n+       if (logOptions?.workspaceRoot && typeof request.path === \"string\" && request.path.length > 0) {\n+         const normalizedWorkspace = normalizePermissionPath(logOptions.workspaceRoot);\n+         const normalizedPath = normalizePermissionPath(request.path);\n+         if (normalizedPath === normalizedWorkspace || normalizedPath.startsWith(normalizedWorkspace + \"/\")) {\n+           return true;\n+         }\n+       }\n        return hasReadGrant || allowedToolEntries.has(\"shell\") || isReadPathAllowedByShellRules(request.path, readablePathPatterns, logOptions?.workspaceRoot);\n```\n\nRelevant helper (unchanged, in same file, for context):\n```js\nfunction normalizePermissionPath(value) {\n  return (\n    String(value || \"\")\n      .trim()\n      .replace(/\\\\/g, \"/\")\n      .replace(/\\/+$/, \"\") || \"/\"\n  );\n}\n```\n\nKey things to scrutinize:\n1. Security/design: this makes the entire workspace tree ALWAYS readable regardless of the workflow's declared tool permissions — even workflows that intentionally omit `read` and restrict to a narrow shell allowlist now get full read access to every file under GITHUB_WORKSPACE, including files from OTHER checkout entries that may have landed inside the same workspace root (multi-checkout workflows, submodules, sparse checkouts of sensitive monorepos), any committed secrets/config files, `.git` internals, etc. Does this undermine the intended least-privilege tool-permission sandboxing model? Is this an intentional broadening that should have been flagged/discussed rather than silently applied as a \"bug fix\"?\n2. Path safety: `normalizePermissionPath` only does string manipulation (trim, backslash-to-slash, trailing slash strip) — no real path resolution, no symlink resolution, no `..` traversal collapsing. Could a request path containing `..` segments or a symlink placed inside the workspace pointing outside of it bypass the intended workspace boundary while still passing the `startsWith(normalizedWorkspace + \"/\")` string check, or conversely could a sibling directory that happens to share the workspace root as a string prefix (e.g. workspace `/home/runner/work/gh-aw/gh-aw` vs a sibling `/home/runner/work/gh-aw/gh-aw-evil`) incorrectly be treated as inside the workspace? Check the `normalizedPath.startsWith(normalizedWorkspace + \"/\")` logic carefully for this prefix-confusion bug.\n3. Test coverage: do the new/modified tests in copilot_sdk_driver.test.cjs actually cover the sibling-directory prefix confusion case, or the symlink-escape case? If not, flag it as a coverage gap.\n4. Any other correctness issues in the exact diff hunks (e.g., using `request.path.length > 0` after already checking `typeof === \"string\"` — redundant/dead check ordering, comment clarity, etc.)\n\nFor full file context if needed, you may read:\n- /home/runner/work/gh-aw/gh-aw/actions/setup/js/copilot_sdk_permissions.cjs (full file)\n- /home/runner/work/gh-aw/gh-aw/actions/setup/js/copilot_sdk_driver.test.cjs (search for \"workspace-root\" and \"always allows read\")\n- /tmp/gh-aw/agent/pr-diff.patch (full diff, capped at 3000 lines)\n\nOutput STRICT JSONL, one finding per line, each line a JSON object with fields:\n{\"file\": \"<path>\", \"line\": <line number in new file version, best estimate>, \"severity\": \"critical|high|medium|low\", \"title\": \"<short title>\", \"description\": \"<detailed explanation of the issue, impact, and suggested fix>\"}\n\nDo not output any other text, headers, or markdown — only JSONL lines. If you find no issues, output a single line: {\"none\": true}"}}}
[copilot-sdk-driver] [sdk-driver] error: Execution failed: Error: No model available. Check policy enablement under GitHub Settings > Copilot
{"type":"subagent.completed","timestamp":"2026-08-02T20:31:33.484Z","data":{"agentName":"general-purpose","toolCallId":"toolu_01Pqxr7HvCSmYC83qDP4teFs"}}

Action Required

Assign this issue to an agent to debug and fix the issue.

Debug with any coding agent

Use this prompt with any coding agent (GitHub Copilot, Claude, Gemini, etc.):

Debug the agentic workflow failure using https://raw.githubusercontent.com/github/gh-aw/main/debug.md

The failed workflow run is at https://github.com/github/gh-aw/actions/runs/30765615691

Manually invoke the agent

Debug this workflow failure using your favorite Agent CLI and the agentic-workflows prompt.

• Start your agent
• Load the agentic-workflows skill from .github/skills/agentic-workflows/SKILL.md or https://github.com/github/gh-aw/blob/main/.github/skills/agentic-workflows/SKILL.md
• Type debug the agentic workflow pr-code-quality-reviewer failure in https://github.com/github/gh-aw/actions/runs/30765615691

Tip

Stop reporting this workflow as a failure

To stop a workflow from creating failure issues, set report-failure-as-issue: false in its frontmatter:

safe-outputs:
  report-failure-as-issue: false

Generated from PR Code Quality Reviewer · 27.4 AIC · ◷

• expires on Aug 3, 2026, 8:35 AM UTC