fix(github): reply in the triggering review thread

[chAwater]

Issue for this PR

Closes #37560

Type of change

• Bug fix
• New feature
• Refactor / code improvement
• Documentation

What does this PR do?

• fix GitHub Action replies in the PR conversation instead of the triggering comment in review thread #37560

When opencode is triggered from an inline review comment (pull_request_review_comment event), the reply is posted to the PR conversation as a top-level comment instead of the review thread it was asked in.

---

the createComment() always calls issues.createComment

opencode/packages/opencode/src/cli/cmd/github.handler.ts

Lines 1264 to 1273 in 45cd8d7

	async function createComment(body: string) {
	// Only called for non-schedule events, so issueId is defined
	console.log("Creating comment...")
	return await octoRest.rest.issues.createComment({
	owner,
	repo,
	issue_number: issueId!,
	body,
	})
	}

which should be pulls.createReplyForReviewComment for review comment,
like the addReaction, using the reactions.createForPullRequestReviewComment

opencode/packages/opencode/src/cli/cmd/github.handler.ts

Lines 1178 to 1189 in 45cd8d7

	async function addReaction(commentType?: "issue" | "pr_review") {
	// Only called for non-schedule events, so triggerCommentId is defined
	console.log("Adding reaction...")
	if (triggerCommentId) {
	if (commentType === "pr_review") {
	return await octoRest.rest.reactions.createForPullRequestReviewComment({
	owner,
	repo,
	comment_id: triggerCommentId!,
	content: AGENT_REACTION,
	})
	}

And I also add a try-catch block to prevent failure (such as no permission or the comment being deleted) and fall back to old behavior.

the comment.in_reply_to_id is the root of the thread, also refer to #26689, but I think its on the wrong file

How did you verify your code works?

(This verification was done with the help of opencode)

Verified end-to-end with a real GitHub PR: the handler's built-in mock-event mode (github run --event ) feeds a webhook payload into the exact code path that runs in GitHub Actions, with the fixed code running locally. All replies were real API calls — no mocking of the GitHub API.

On a closed PR: replies triggered from a top-level review comment, a reply inside a thread, and a file-level comment ("Add comment on file") all land inside the review thread with the correct in_reply_to_id, while regular timeline comments still post as top-level. The fallback path is preserved, so a failed reply degrades to the old behavior instead of losing the response.

BTW: I found an unrelated bug on the reaction emoji with use_github_token during the verification, maybe I will report it later 😄

Screenshots / recordings

None

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR