Failed to apply bundle: The process '/usr/bin/git' failed with exit code 1\\n##[error]✗ Message 1 (create_pull_request) failed: Failed to apply bundle\\n```\\n\\nObserved on `worker-fix` runs in `gominimal/min-aw` after another PR merged to `main` between the `agent` job and the `safe_outputs` job.\\n\\n## Root cause\\n\\nThe lock-file's safe_outputs job checks out the host repo with `actions/checkout` at `fetch-depth: 1`. Then it runs `git fetch origin main` and `git fetch \\u003cbundle\\u003e`. The bundle was generated by the agent based on whatever `main` was at agent-time. If `main` advanced between agent-time and safe_outputs-time (e.g., a different PR merged), the bundle's base commit is no longer reachable from the shallow tip → `Repository lacks these prerequisite commits`.\\n\\nReproduction is racy but reliable when:\\n1. Agent computes patch against `main` = SHA `A` at T1.\\n2. PR `P` merges to `main` at T2, advancing to SHA `B` (with `A` as ancestor).\\n3. Safe_outputs runs at T3, checks out `main` with `fetch-depth: 1` → only `B` in local repo, `A` not present.\\n4. `git fetch \\u003cbundle\\u003e` fails because the bundle's base SHA = `A` is unreachable.\\n\\nConcrete failing run: https://github.com/gominimal/min-aw/actions/runs/25904423290\\n- Bundle's prerequisite SHA: `172f87a830f57a29470efe7646d141069434a893` (was main HEAD when the agent ran; corresponds to a PR merge that happened just before)\\n- Main HEAD when safe_outputs ran: an advanced commit that descended from `172f87a` but `fetch-depth: 1` only had the tip\\n\\n## Why fetch-depth: 1 isn't enough here\\n\\nThe safe_outputs step's checkout is fresh — actions/checkout doesn't reuse the agent job's working tree. So even though the agent had access to `main@A` when it built the bundle, that history is gone by the time safe_outputs runs. `git fetch \\u003cbundle\\u003e` needs `A` reachable in the local repo, but the shallow clone only has the current tip.\\n\\n## Suggested fixes (any of the following)\\n\\n1. **Bump `fetch-depth`** on the safe_outputs checkout step to a larger value (50? 100?) — covers typical PR-merge races.\\n2. **Unshallow before bundle apply**: after the existing `git fetch origin main`, add `git fetch --unshallow origin main` (or `git fetch --depth=2147483647`) when applying a bundle.\\n3. **Fetch the bundle's base SHA explicitly**: bundles already encode their base. Parse it and `git fetch origin \\u003cbase-sha\\u003e` before `git fetch \\u003cbundle\\u003e`.\\n4. **Have the safe_outputs handler retry once with `--unshallow`** if the first apply fails with `lacks these prerequisite commits`.\\n\\n## Workaround for consumers\\n\\nNone at the consumer level — the safe_outputs job is compiled into the lock file by gh-aw. Repo owners can avoid the race by **not merging other PRs while a chore-fix is in flight**, but that's brittle. The daily cron retry helps because the second attempt is usually against a stable main, but agents can keep filing failure-report issues if the race repeats.\\n\\n## Related\\n\\n- Failure-report safe-output fires when this happens, filing a new issue per failed run — amplifies noise during clearance loops.\",\"closed_at\":\"2026-05-15T13:55:18Z\",\"closed_by\":{\"avatar_url\":\"https://avatars.githubusercontent.com/u/4175913?v=4\",\"events_url\":\"https://api.github.com/users/pelikhan/events{/privacy}\",\"followers_url\":\"https://api.github.com/users/pelikhan/followers\",\"following_url\":\"https://api.github.com/users/pelikhan/following{/other_user}\",\"gists_url\":\"https://api.github.com/users/pelikhan/gists{/gist_id}\",\"gravatar_id\":\"\",\"html_url\":\"https://github.com/pelikhan\",\"id\":4175913,\"login\":\"pelikhan\",\"node_id\":\"MDQ6VXNlcjQxNzU5MTM=\",\"organizations_url\":\"https://api.github.com/users/pelikhan/orgs\",\"received_events_url\":\"https://api.github.com/users/pelikhan/received_events\",\"repos_url\":\"https://api.github.com/users/pelikhan/repos\",\"site_admin\":true,\"starred_url\":\"https://api.github.com/users/pelikhan/starred{/owner}{/repo}\",\"subscriptions_u

Unable to download artifact(s): Artifact not found for name: cache-memory Please ensure that your artifact is not expired and the artifact was uploaded using a compatible version of toolkit/upload-artifact. For more information, visit the GitHub Artifacts FAQ: https://github.com/actions/toolkit/blob/main/packages/artifact/docs/faq.md

1 safe output(s) failed: - add_labels: No issue/PR number available

✗ Message 2 (add_labels) failed: No issue/PR number available

No files were found with the provided path: /tmp/gh-aw/cache-memory. No artifacts will be uploaded.

Could not compare frontmatter hashes — assuming lock file is outdated\n##[error]ERR_CONFIG: Lock file '.github/workflows/\u003cchore\u003e.lock.yml' is outdated\n or unverifiable! Could not verify frontmatter hash for\n '.github/workflows/\u003cchore\u003e.md'. Run 'gh aw compile' to regenerate the lock file.\n```\n\nThe check_workflow_timestamp_api.cjs activation step then sets `stale_lock_file_failed=true`, and the conclusion job marks the whole run failed before the agent ever runs.\n\nConcrete reproducer: gominimal/min-ctl run [25906428806](https://github.com/gominimal/min-ctl/actions/runs/25906428806) calls `gominimal/min-aw/.github/workflows/worker-fix.lock.yml@v0.6.3`. Both repos private, same org. Fails as above on every dispatch.\n\n## Root cause\n\n`check_workflow_timestamp_api.cjs` issues the Contents API call against the callee repo using `GITHUB_TOKEN` from the caller's runner. For a private callee:\n\n- `GITHUB_TOKEN` on a workflow run is **repo-scoped** to the running repo (the

Could not compare frontmatter hashes — assuming lock file is outdated\n##[error]ERR_CONFIG: Lock file '.github/workflows/\u003cchore\u003e.lock.yml' is outdated\n or unverifiable! Could not verify frontmatter hash for\n '.github/workflows/\u003cchore\u003e.md'. Run 'gh aw compile' to regenerate the lock file.\n```\n\nThe check_workflow_timestamp_api.cjs activation step then sets `stale_lock_file_failed=true`, and the conclusion job marks the whole run failed before the agent ever runs.\n\nConcrete reproducer: gominimal/min-ctl run [25906428806](https://github.com/gominimal/min-ctl/actions/runs/25906428806) calls `gominimal/min-aw/.github/workflows/worker-fix.lock.yml@v0.6.3`. Both repos private, same org. Fails as above on every dispatch.\n\n## Root cause\n\n`check_workflow_timestamp_api.cjs` issues the Contents API call against the callee repo using `GITHUB_TOKEN` from the caller's runner. For a private callee:\n\n- `GITHUB_TOKEN` on a workflow run is **repo-scoped** to the running repo (the caller, e.g. `gominimal/min-ctl`).\n- The Contents API on a private repo requires read access to that specific repo.\n- `gominimal/min-ctl`'s `GITHUB_TOKEN` has no scope on `gominimal/min-aw` → 404, even though both repos are in the same org and workflow_call itself was already authorized via repo-actions-access settings.\n\nThis works fine when the callee is **public** (`elastic/ai-github-actions` is public; their consumers don't see this) — public Contents API doesn't require auth. The gap is private-callee-private-caller.\n\n## Why the existing fallbacks don't help\n\n1. **API path** uses `GITHUB_TOKEN` → 404 for private callees.\n2. **`GH_AW_GITHUB_TOKEN` fallback secret slot** is declared optional in the lock.yml's `workflow_call.secrets`. Consumers *can* provide a token here, but the documentation/templates don't make this clear, and there's no practical way to mint a short-lived cross-repo token without long-lived PAT storage (security cost).\n3. **Local filesystem fallback** looks for the lock.yml on the caller's checkout. Consumers using the wrapper distribution pattern don't ship `.lock.yml` files locally (that's the point — thin wrappers).\n\n## Proposed fix\n\nThe lock.yml already receives `APP_PRIVATE_KEY` via `workflow_call.secrets` (used for safe-output writes via `actions/create-github-app-token`). If the corresponding GitHub App is installed on the callee repo as well, an App-minted installation token has cross-repo Contents read access.\n\n`check_workflow_timestamp_api.cjs` should:\n\n1. Detect cross-repo invocation (it already does — emits \"Cross-repo invocation detected\" log).\n2. Detect that the initial Contents API call returned 404 / 401 / 403.\n3. Mint a fresh installation token using `APP_PRIVATE_KEY` + `vars.APP_ID` (both already available to the activation step), scoped to the callee repo.\n4. Retry the Contents API call with the minted token.\n5. If the mint fails (no APP_PRIVATE_KEY in secrets, App not installed on callee, etc.), fall through to today's behavior with a clearer error message: \"Configure GH_AW_GITHUB_TOKEN with cross-repo Contents read access, or install the gh-aw App on the callee repo.\"\n\nAlternative if internal mint is too invasive: emit a clearer error directing consumers to set up `GH_AW_GITHUB_TOKEN`. The current message (\"outdated or unverifiable\") sends users toward `gh aw compile`, which doesn't address the auth gap.\n\n## Workaround for current users\n\nShip `.lock.yml` mirrors on the consumer side alongside `.md` mirrors. The filesystem fallback then succeeds. Trade-off: ~80–90 KB per chore on the consumer (defeats the thin-wrapper goal). See [gominimal/min-ctl#66](https://github.com/gominimal/min-ctl/pull/66) for the workaround in practice.\n\n## Related\n\n- github/gh-aw#32310 — bundle-apply race in safe_outputs (separate root cause, same setup)","comments":{"nodes":[{"author":{"login":"github-actions"},"authorAssociation":"CONTRIBUTOR","body":"🏕️ Scout on patrol! [Scout](https://github.com/github/gh-aw/actions/runs/25950059255) is blazing trails

Could not compare frontmatter hashes — assuming lock file is outdated\n##[error]ERR_CONFIG: Lock file '.github/workflows/\u003cchore\u003e.lock.yml' is outdated\n or unverifiable! Could not verify frontmatter hash for\n '.github/workflows/\u003cchore\u003e.md'. Run 'gh aw compile' to regenerate the lock file.\n```\n\nThe check_workflow_timestamp_api.cjs activation step then sets `stale_lock_file_failed=true`, and the conclusion job marks the whole run failed before the agent ever runs.\n\nConcrete reproducer: gominimal/min-ctl run [25906428806](https://github.com/gominimal/min-ctl/actions/runs/25906428806) calls `gominimal/min-aw/.github/workflows/worker-fix.lock.yml@v0.6.3`. Both repos private, same org. Fails as above on every dispatch.\n\n## Root cause\n\n`check_workflow_timestamp_api.cjs` issues the Contents API call against the callee repo using `GITHUB_TOKEN` from the caller's runner. For a private callee:\n\n- `GITHUB_TOKEN` on a workflow run is **repo-scoped** to the running repo (the caller, e.g. `gominimal/min-ctl`).\n- The Contents API on a private repo requires read access to that specific repo.\n- `gominimal/min-ctl`'s `GITHUB_TOKEN` has no scope on `gominimal/min-aw` → 404, even though both repos are in the same org and workflow_call itself was already authorized via repo-actions-access settings.\n\nThis works fine when the callee is **public** (`elastic/ai-github-actions` is public; their consumers don't see this) — public Contents API doesn't require auth. The gap is private-callee-private-caller.\n\n## Why the existing fallbacks don't help\n\n1. **API path** uses `GITHUB_TOKEN` → 404 for private callees.\n2. **`GH_AW_GITHUB_TOKEN` fallback secret slot** is declared optional in the lock.yml's `workflow_call.secrets`. Consumers *can* provide a token here, but the documentation/templates don't make this clear, and there's no practical way to mint a short-lived cross-repo token without long-lived PAT storage (security cost).\n3. **Local filesystem fallback** looks for the lock.yml on the caller's checkout. Consumers using the wrapper distribution pattern don't ship `.lock.yml` files locally (that's the point — thin wrappers).\n\n## Proposed fix\n\nThe lock.yml already receives `APP_PRIVATE_KEY` via `workflow_call.secrets` (used for safe-output writes via `actions/create-github-app-token`). If the corresponding GitHub App is installed on the callee repo as well, an App-minted installation token has cross-repo Contents read access.\n\n`check_workflow_timestamp_api.cjs` should:\n\n1. Detect cross-repo invocation (it already does — emits \"Cross-repo invocation detected\" log).\n2. Detect that the initial Contents API call returned 404 / 401 / 403.\n3. Mint a fresh installation token using `APP_PRIVATE_KEY` + `vars.APP_ID` (both already available to the activation step), scoped to the callee repo.\n4. Retry the Contents API call with the minted token.\n5. If the mint fails (no APP_PRIVATE_KEY in secrets, App not installed on callee, etc.), fall through to today's behavior with a clearer error message: \"Configure GH_AW_GITHUB_TOKEN with cross-repo Contents read access, or install the gh-aw App on the callee repo.\"\n\nAlternative if internal mint is too invasive: emit a clearer error directing consumers to set up `GH_AW_GITHUB_TOKEN`. The current message (\"outdated or unverifiable\") sends users toward `gh aw compile`, which doesn't address the auth gap.\n\n## Workaround for current users\n\nShip `.lock.yml` mirrors on the consumer side alongside `.md` mirrors. The filesystem fallback then succeeds. Trade-off: ~80–90 KB per chore on the consumer (defeats the thin-wrapper goal). See [gominimal/min-ctl#66](https://github.com/gominimal/min-ctl/pull/66) for the workaround in practice.\n\n## Related\n\n- github/gh-aw#32310 — bundle-apply race in safe_outputs (separate root cause, same setup)","comments":{"nodes":[{"author":{"id":"MDQ6VXNlcjI5NDE5Njcz","login":"kkruel8100","name":"Kimberly Kruel"},"authorAssociation":"NONE","body":"Experiencing same issue. Proposed workaround is not viable on centra

Could not compare frontmatter hashes — assuming lock file is outdated\n##[error]ERR_CONFIG: Lock file '.github/workflows/<chore>.lock.yml' is outdated\n or unverifiable! Could not verify frontmatter hash for\n '.github/workflows/<chore>.md'. Run 'gh aw compile' to regenerate the lock file.\n```\n\nThe check_workflow_timestamp_api.cjs activation step then sets `stale_lock_file_failed=true`, and the conclusion job marks the whole run failed before the agent ever runs.\n\nConcrete reproducer: gominimal/min-ctl run [25906428806](https://github.com/gominimal/min-ctl/actions/runs/25906428806) calls `gominimal/min-aw/.github/workflows/worker-fix.lock.yml@v0.6.3`. Both repos private, same org. Fails as above on every dispatch.\n\n## Root cause\n\n`check_workflow_timestamp_api.cjs` issues the Contents API call against the callee repo using `GITHUB_TOKEN` from the caller's runner. For a private callee:\n\n- `GITHUB_TOKEN` on a workflow run is **repo-scoped** to the running repo (the caller, e.g. `gominimal/min-ctl`).\n- The Contents API on a private repo requires read access to that specific repo.\n- `gominimal/min-ctl`'s `GITHUB_TOKEN` has no scope on `gominimal/min-aw` → 404, even though both repos are in the same org and workflow_call itself was already authorized via repo-actions-access settings.\n\nThis works fine when the callee is **public** (`elastic/ai-github-actions` is public; their consumers don't see this) — public Contents API doesn't require auth. The gap is private-callee-private-caller.\n\n## Why the existing fallbacks don't help\n\n1. **API path** uses `GITHUB_TOKEN` → 404 for private callees.\n2. **`GH_AW_GITHUB_TOKEN` fallback secret slot** is declared optional in the lock.yml's `workflow_call.secrets`. Consumers *can* provide a token here, but the documentation/templates don't make this clear, and there's no practical way to mint a short-lived cross-repo token without long-lived PAT storage (security cost).\n3. **Local filesystem fallback** looks for the lock.yml on the caller's checkout. Consumers using the wrapper distribution pattern don't ship `.lock.yml` files locally (that's the point — thin wrappers).\n\n## Proposed fix\n\nThe lock.yml already receives `APP_PRIVATE_KEY` via `workflow_call.secrets` (used for safe-output writes via `actions/create-github-app-token`). If the corresponding GitHub App is installed on the callee repo as well, an App-minted installation token has cross-repo Contents read access.\n\n`check_workflow_timestamp_api.cjs` should:\n\n1. Detect cross-repo invocation (it already does — emits \"Cross-repo invocation detected\" log).\n2. Detect that the initial Contents API call returned 404 / 401 / 403.\n3. Mint a fresh installation token using `APP_PRIVATE_KEY` + `vars.APP_ID` (both already available to the activation step), scoped to the callee repo.\n4. Retry the Contents API call with the minted token.\n5. If the mint fails (no APP_PRIVATE_KEY in secrets, App not installed on callee, etc.), fall through to today's behavior with a clearer error message: \"Configure GH_AW_GITHUB_TOKEN with cross-repo Contents read access, or install the gh-aw App on the callee repo.\"\n\nAlternative if internal mint is too invasive: emit a clearer error directing consumers to set up `GH_AW_GITHUB_TOKEN`. The current message (\"outdated or unverifiable\") sends users toward `gh aw compile`, which doesn't address the auth gap.\n\n## Workaround for current users\n\nShip `.lock.yml` mirrors on the consumer side alongside `.md` mirrors. The filesystem fallback then succeeds. Trade-off: ~80–90 KB per chore on the consumer (defeats the thin-wrapper goal). See [gominimal/min-ctl#66](https://github.com/gominimal/min-ctl/pull/66) for the workaround in practice.\n\n## Related\n\n- github/gh-aw#32310 — bundle-apply race in safe_outputs (separate root cause, same setup)","is_error":false}]},"parent_tool_use_id":null,"session_id":"40b1ec9f-f0df-4c84-b5ba-aa2f559027a1","uuid":"fd7becd8-a0fb-4bbd-b34c-8e6b03a6ef49","timestamp":"2026-05-16T02:10:28.588Z","tool_use_result":{"stdout":"title:\tLockdown

1 message(s) failed to process