[LOW] Trailing slash on path: qualifier

The new qualifier path:.github/workflows is a substring match, so it could theoretically match paths like .github/workflows-extra/ in addition to the intended .github/workflows/ directory. Using path:.github/workflows/ (with a trailing slash) is the more precise form and is the pattern documented in GitHub code search examples.

That said, the additional content filter ("docker/cagent-action/.github/workflows/review-pr.yml@") and language:YAML qualifier make any false-positive match practically impossible, so this has no functional impact.

No change — the content filter ("docker/cagent-action/.github/workflows/review-pr.yml@") already makes false positives impossible here.

Fair enough — you're right that the content filter makes this a non-issue in practice. Thanks for considering it!

sed -i '' breaks on GNU sed / Linux (macOS-only syntax)

The script uses sed -i '' (BSD sed syntax for in-place editing with no backup). On GNU sed — which is what GitHub Actions Linux runners use — this silently misbehaves: GNU sed treats the empty string '' as the sed script (a no-op), then interprets the actual s|...|...|g expression as a filename, producing No such file or directory. The subshell exits non-zero, GIT_RESULT captures the failure, and every consumer repo is silently skipped with "Git operations failed".

The script is documented as runnable both locally (macOS) and in CI (Linux). Use a cross-platform form:

# Cross-platform: create and remove a backup file
sed -i.bak "s|...|...|g" "${FILE_PATH}" && rm -f "${FILE_PATH}.bak"
# Or use perl:
perl -i -pe 's|docker/cagent-action/\.github/workflows/review-pr\.yml\@.*|docker/cagent-action/.github/workflows/review-pr.yml\@${SHA} # ${VERSION}|g' "${FILE_PATH}"

Fixed — switched to sed -i.bak + rm for cross-platform compat.

Confirmed — the fix looks good! The sed -i.bak + rm pattern works correctly on both GNU sed (Linux) and BSD sed (macOS).

Silent API failure makes complete outage indistinguishable from zero results

Both 2>/dev/null and || true are applied to the gh api --paginate discovery call. If the call fails due to rate limiting, expired credentials, network error, or GitHub API degradation, REPOS_RAW is set to an empty string and the script exits 0 with "No consumer repos found." — identical output to a legitimate zero-result search. Release automation reports success while zero consumer repos were updated.

Consider at minimum capturing stderr separately to detect failures:

REPOS_RAW="$(gh api --method GET --paginate '/search/code?per_page=100' \
  -f q="${SEARCH_QUERY}" \
  --jq '[.items[] | {repo: .repository.full_name, path: .path}] | unique_by(.repo) | .[] | "\(.repo) \(.path)"')"
# Let gh's non-zero exit propagate — set -euo pipefail will abort the script

Fixed — removed 2>/dev/null || true so set -e propagates API failures properly.

Perfect — thanks for the fix! The API call will now fail loudly when GitHub rate-limits, auth expires, or returns an error, preventing silent zero-result scenarios from being treated as success.

git push --force destroys manual commits on PR branches

The branch is pushed with --force, which unconditionally overwrites the remote branch. If a reviewer or the PR author has pushed fixup commits to the auto/update-cagent-action branch in a consumer repo since the last automated run, those commits are permanently lost on the next execution.

Use --force-with-lease instead — it aborts safely if the remote ref has diverged from what the local clone fetched:

git push --force-with-lease origin "${BRANCH_NAME}" -q

No change — this branch is exclusively managed by this script. Nobody should be pushing manual commits to auto/update-cagent-action.

Silent PR creation/update failures inflate the success counter

Both gh pr edit and gh pr create are followed by 2>/dev/null || true, suppressing all errors and exit codes. If either call fails (insufficient permissions, invalid head ref, API error), the script still prints "✅ Done" and increments COUNT_UPDATED. The summary then shows e.g. "Updated: 5" when zero PRs may have actually been created or updated.

Additionally, gh pr create prints the new PR URL to stdout — 2>/dev/null silently drops it, making newly created PRs unlocatable from the script output.

Consider removing the error suppression and letting failures surface:

gh pr create \
  --repo "${REPO}" \
  --head "${PR_HEAD}" \
  --title "chore: update cagent-action to ${VERSION}" \
  --body-file "${PR_BODY_FILE}" || { COUNT_FAILED=$((COUNT_FAILED + 1)); continue; }

Fixed — removed 2>/dev/null || true from both paths. PR creation now prints the URL on success and increments COUNT_FAILED on failure instead of silently counting as success.

Confirmed — the fix looks good! Both paths now properly handle failures:

• gh pr edit increments COUNT_FAILED on non-zero exit
• gh pr create increments COUNT_FAILED and surfaces the error message on failure
• On success, gh pr create now captures and displays the PR URL

The counters now accurately reflect reality, and newly created PRs are immediately visible in the output. Thanks for the quick turnaround!