Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions .github/workflows/avenger.lock.yml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

15 changes: 7 additions & 8 deletions .github/workflows/avenger.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ tools:
cli-proxy: true

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/diagnosing-bugs] Good: toolsets: [default, actions] now matches the actions: read permission already granted at the top of this file, closing the denial. One gap remains — the "If an Actions tool is unavailable" fallback text (previously at the end of Step 3) that named the exact missing allowlist entry was deleted in this PR, even though the issue's "Done when" criterion requires "Missing tool reports name the exact allowlist entry to add." Consider keeping a short fallback note for future regressions (e.g. if actions toolset access is revoked again).

@copilot please address this.

github:
mode: local
toolsets: [default]
toolsets: [default, actions]
bash: ["*"]
edit:
sandbox:
Expand Down Expand Up @@ -157,9 +157,7 @@ Before doing anything:
1. **If CI Status is "success"**: CI was passing at activation time — call `noop` immediately with "CI is passing on main branch - no cleanup needed" and **stop**.
2. **If CI Status is "failure"**: Proceed with the repair sequence below using the CI Run ID from the pre-check.
3. **If CI Status is missing or ambiguous**: Re-verify using the live API:
```bash
gh run list --workflow=ci.yml --branch=main --limit=2 --json conclusion,status,databaseId
```
use the GitHub Actions MCP tools to list completed runs for `ci.yml` on `main`; do not use `gh run list`.
- **If both completed runs are "success"**: CI has self-healed. Call `noop` and **stop**.
- **Otherwise**: Proceed with the repair sequence below.

Expand Down Expand Up @@ -193,16 +191,17 @@ git diff --name-only HEAD origin/main | grep '^\.github/workflows/.*\.md$'

## Step 3: Inspect the failing CI run first (mandatory)

Use the CI Run ID from pre-check and identify the first failed job and failing signal before running any local validation:
Use the GitHub Actions MCP tools, not `gh run view` (the agent's `gh` CLI is unauthenticated), and identify the first failed job and failing signal before running any local validation:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This swaps out the unauthenticated gh call for an Actions MCP path, but the prompt now hard-codes a tool contract (actions_list with method: list_workflow_jobs and resource_id) that does not match the Actions tools gh-aw exposes, so Avenger can still fail before it ever reaches the job logs.

💡 Why this blocks the workflowThere is no prior-art usage of method: list_workflow_jobs or resource_id in this repo, while generated manifests expose Actions reads as dedicated MCP tools such as mcp__github__actions_list and mcp__github__get_job_logs. If the agent follows the literal contract here, it will burn a denial or validation error and noop instead of triaging CI. Please describe the actual tool shape the runtime exposes, or keep the step tool-agnostic instead of inventing parameter names.

```bash
gh run view "${{ needs.check_ci_status.outputs.ci_run_id }}" --json jobs
```
1. Call `actions_list` with `method: list_workflow_jobs` and `resource_id` set to the CI Run ID from pre-check.
2. Identify the first failed job.
3. Call `get_job_logs` with that job's ID and inspect the failing output.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[/diagnosing-bugs] This mandatory step still invokes gh run view "${{ needs.check_ci_status.outputs.ci_run_id }}" --json jobs using the agent's gh CLI, but line 87 of this same PR's description states "the agent's gh CLI is unauthenticated" and the companion Step-0 fallback at line 161 also reverts to raw gh run list. If that premise is true, this gh run view call will fail the same way the original bug (#67444/#67431) did, and the "If an Actions tool is unavailable" fallback guidance that named the exact tools.github.toolsets: [default, actions] entry was removed, so a future denial will no longer self-document the fix.

💡 Root cause check

Compare with the compiled lock file: toolsets: [default, actions] was reverted to [default] and GITHUB_TOOLSETS dropped actions, yet the body text keeps a gh run view/gh run list based repair flow instead of the actions_list/get_job_logs MCP calls that were in the issue's intended fix. If gh really is unauthenticated for this workflow, Step 0's and Step 3's gh run list/gh run view calls are dead code that will always fail, silently defeating the "CI self-healed" and "inspect failing run" branches. Verify whether gh is authenticated here (it may be, via GH_TOKEN as seen at line 63) — if so, document that explicitly instead of claiming otherwise elsewhere in the PR, since the inconsistency between the PR description and the body text is itself a latent regression risk.

@copilot please address this.


Then inspect only the failing job logs and extract the concrete failure category (formatting, lint, tests, wasm golden, compile, or other).

- If the failure is not actionable or is clearly infra/transient (network outage, rate limit, runner outage), call `noop` with a brief explanation and stop.
- If actionable, apply the smallest fix that maps directly to the failure signal.
- If an Actions tool is unavailable, keep the denial text and name the exact allowlist entry needed: add `actions` to `tools.github.toolsets`.

## Step 4: Format sources (only when relevant)

Expand Down
2 changes: 1 addition & 1 deletion .github/workflows/codex-github-remote-mcp-test.lock.yml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

6 changes: 5 additions & 1 deletion .github/workflows/codex-github-remote-mcp-test.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,13 +42,17 @@ Test that the GitHub remote MCP server works with Codex engine by listing 3 open
2. Filter for `state: OPEN`
3. Extract issue numbers and titles

If the MCP response confirms that issues were found but their contents were filtered by the integrity policy, treat this as an expected policy result. Report the number found, state that titles were withheld by the policy, and do not lower trust requirements or retry through another API/tool.

### Expected Output

Output a brief message with:
- ✅ Test passed
- ✅ Test passed (or, when issue contents are filtered, test passed for MCP access and integrity-policy enforcement)
- Number of issues retrieved
- Sample issue numbers and titles

When contents are filtered, say that sample titles are unavailable rather than inventing or bypassing the filter.

Example:
```
✅ Codex + GitHub Remote MCP Test PASSED
Expand Down
Loading
Loading