fix(claude): plumb track_progress so workflows stop clobbering each other's PR comment

[sfreudenthaler]

Problem

anthropics/claude-code-action@v1 finds the comment to (re)use with no per-workflow marker — src/github/operations/comments/create-initial.ts:

const existingComment = comments.data.find((comment) => {
  const idMatch = comment.user?.id === CLAUDE_APP_BOT_ID;      // 209825114
  const botNameMatch = comment.user?.type === "Bot" && comment.user?.login.toLowerCase().includes("claude");
  ...
});

Any comment authored by the Claude app bot matches. So two Anthropic-path workflows on the same PR share one comment, and the later run resets it to "Claude Code is working…" and writes over the earlier result.

Observed in dotCMS/core (#36761, PR #36759) — one comment, eight edits, two different workflows:

time	run	content
20:10:08	Claude AI Orchestrator	creates comment
20:11:23	"	Code Review: PR #36759
20:12:17	Claude AI Rollback Safety Check	reset to "Claude Code is working…" — review gone
20:13:50	"	Rollback-Safety Analysis

track_progress was hardcoded "true" in claude-executor.yml, so consumers had no way to opt a secondary workflow out of the progress comment.

Change

track_progress input on claude-executor.yml and claude-orchestrator.yml, default true — no behaviour change for existing consumers. Workflows that report through their own marker comment or a label pass false and leave the sticky comment to its single owner.

The bedrock-generic / harness / codex paths already namespace their markers via sticky_namespace and are untouched.

Follow-up

• Needs a v3.x release + v3 tag move before the core-side fix (Claude AI workflows overwrite each other's PR comments (rollback-safety clobbers the code review) core#36761) can reference track_progress.
• Real upstream fix is a namespaced marker in claude-code-action; worth an issue there.

[github-actions]

🤖 Bedrock Review — qwen.qwen3-next-80b-a3b

New Issues

• 🟡 Medium: .github/workflows/claude-executor.yml:71 — The PR adds track_progress as an input but does not change the underlying action’s comment lookup logic, which still uses a hardcoded key "authored by the Claude app bot" without per-workflow isolation. This means concurrent workflows with track_progress: true will still overwrite each other’s comments — the input alone does not resolve the race condition. What to verify: Confirm the external action’s comment lookup is unchanged and that track_progress: false is the only effective mitigation.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:91 — Same as above: track_progress input is added but the action’s comment key remains globally shared. No mechanism is introduced to enforce mutual exclusion or namespace comments. What to verify: Ensure the downstream action does not use the input to modify its comment lookup behavior.

Existing

• 🟡 Medium: .github/workflows/claude-executor.yml:196 — The use_sticky_comment: true with no per-workflow identifier remains unchanged and continues to pose the same race condition risk. The PR did not alter this line’s behavior.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:259 — The use_sticky_comment input is passed through unchanged, and the underlying action still uses the non-namespaced comment key. The PR did not fix this.

Resolved

• ✅ .github/workflows/claude-executor.yml:196 — The hardcoded "true" for track_progress is now parameterized via ${{ inputs.track_progress }}, allowing users to disable progress comments. This enables the intended mitigation (though does not fix the root cause).
• ✅ .github/workflows/claude-executor.yml:203 — Same as above: track_progress is now configurable, not hardcoded.
• ✅ .github/workflows/claude-orchestrator.yml:259 — track_progress is now passed through input instead of hardcoded, enabling user control.

---

_{Run: #30303356754 · tokens: in: 2098 · out: 666 · total: 2764}

[sfreudenthaler]

Acknowledging the review — the findings are factually correct and intentional, so recording the reasoning rather than changing the approach.

Correct: the action's comment lookup is unchanged and not configurable. src/github/operations/comments/create-initial.ts matches on a file-local hardcoded CLAUDE_APP_BOT_ID = 209825114 plus login.toLowerCase().includes("claude"). The bot_id / bot_name inputs only feed configureGitAuth (git commit identity) — they do not reach the lookup, so a workflow cannot rename its way out of the collision. track_progress: false is indeed the only effective mitigation available to a consumer.

One correction: this is not a race condition. Any second Anthropic-path workflow with track_progress: true overwrites the first one's comment deterministically, whatever the timing — ordering decides only who wins. That matters because "race" invites a mutex/concurrency-group fix, and serializing the workflows would not help at all.

On enforcement: nothing here can enforce mutual exclusion — the state lives in the PR's comment list, not in this repo. Checked the blast radius: of the 10 consumer repos on @v3, only dotCMS/core runs more than one Anthropic-path workflow per PR (orchestrator + rollback-safety + backend-reviewer); the other nine have exactly one and are unaffected either way. core sets track_progress: false on the latter two in dotCMS/core#36762.

Documented the limitation and the one-owner convention in the README (Dual Invocation Troubleshooting §6) so it is written down where consumers look, instead of living in this PR thread. The real fix is a namespaced marker upstream in claude-code-action.

[sfreudenthaler]

looks good. I see the review feedback but it's a known limitation at this point. only the code reviewer uses the default comment and it just updates that it's working. then when done it posts it's own comment

[github-actions]

🤖 Bedrock Review — qwen.qwen3-next-80b-a3b

New Issues

• 🟡 Medium: .github/workflows/claude-executor.yml:71 — track_progress input added but underlying action still uses hardcoded comment key 'authored by the Claude app bot', so race condition persists.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:91 — track_progress input added but underlying action still uses hardcoded comment key 'authored by the Claude app bot', so race condition persists.
• 🟡 Medium: .github/workflows/claude-executor.yml:196 — use_sticky_comment: true with no per-workflow identifier remains unchanged and continues to pose race condition risk.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:259 — use_sticky_comment input passed through unchanged; underlying action still uses non-namespaced comment key.

Existing

• 🟡 Medium: .github/workflows/claude-executor.yml:71 — track_progress input added but underlying action still uses hardcoded comment key 'authored by the Claude app bot', so race condition persists.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:91 — track_progress input added but underlying action still uses hardcoded comment key 'authored by the Claude app bot', so race condition persists.
• 🟡 Medium: .github/workflows/claude-executor.yml:196 — use_sticky_comment: true with no per-workflow identifier remains unchanged and continues to pose race condition risk.
• 🟡 Medium: .github/workflows/claude-orchestrator.yml:259 — use_sticky_comment input passed through unchanged; underlying action still uses non-namespaced comment key.

Resolved

• ✅ .github/workflows/claude-executor.yml:196 — track_progress now configurable via input, reducing risk if used correctly (though underlying issue remains)
• ✅ .github/workflows/claude-orchestrator.yml:259 — track_progress now passed through input, reducing risk if used correctly (though underlying issue remains)

---

_{Run: #30303843724 · tokens: in: 2453 · out: 674 · total: 3127}