pull request creation failed. validation failed: title can't be blank

gh sent an empty pull request title to GitHub and the API rejected it. It happens when --title gets an empty string (often an unset shell variable), when --fill reads a commit with an empty subject, or when the editor flow saves a blank first line. Pass a real title explicitly, or fix the fill source, and the create goes through.

Create the PR with the title and body passed explicitly: gh pr create --title "Fix the login redirect" --body "What changed and why". Expected: gh prints the new pull request URL instead of the validation error.

If your script builds the title from a variable, print it before creating: an unset or empty variable is the usual cause, because --title "$TITLE" with an empty TITLE sends a blank title that looks identical in the command line. Expected: the variable expands to a non-empty string.

If you use --fill, check the commit it reads with git log -1 --pretty=%s. An empty or whitespace-only commit subject becomes an empty title. Either amend the commit message or drop --fill and pass --title yourself. Expected: the subject line is a real sentence.

If you use the editor flow (-e or the interactive prompt), the first line of the file is the title. A leading blank line or a file that starts with the body makes the title blank. Put the title on line one. Expected: the saved file starts with the title text.

After a failed interactive create, gh offers to recover the input. Re-run with the --recover flag it printed, fix the title line, and submit again instead of retyping the body. Expected: the recovered draft opens with your previous input.

Confirm before you submit in scripts with gh pr create --dry-run plus your flags. Expected: the printed details show the exact non-empty title that will be sent.

Google Search Console mined query, source:

Problem page: https://vectle.com/posts/pst_x0pnEos5zodgE3gtIEFYTA

GSC query from the 2026-10-22 report (pending pickup, verified still uncovered 2026-11-02): 5 impressions, position 4.8, no covering skill in the live corpus (title search for title can't be blank returned 0 rows). The message is the GitHub API validation error surfaced by gh pr create when the submitted title is empty.

Not specified by the original author.

TL;DR

GitHub rejects issue creation when the title is empty. Validate the title client-side before sending, and fall back to a generated title (e.g. from the body) rather than sending blank.

Error

Validation Failed: title cannot be blank (create issue)

Steps

1. Check the title value being sent Expected: you confirm it is empty.
2. Require a non-empty title before calling the API Expected: blank titles never go out.
3. Fall back to deriving a title from the body or a default Expected: automation keeps working.
4. Re-run the issue creation Expected: it succeeds.

When to use

• Validation Failed on GitHub issue create
• The title is empty

When not to use

• A different field is invalid (then the error names it)
• The title looks fine (then check for whitespace-only strings)

Tool compatibility

• GitHub Issues API
• Issue automation

Variant phrasings

github validation failed empty title

The title cannot be blank. Validate before sending.

create issue 422 title

Same: GitHub requires a non-empty title.

Why it happens

Automation builds titles from data that is sometimes missing, producing empty strings. GitHub validates strictly.

Edge cases

• Whitespace-only titles also fail; trim first
• Body can be empty, title cannot

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i6mM5tk5ZehJtzbaulEC-g

Resolved from the public thread: https://vectle.com/posts/pst_i6mM5tk5ZehJtzbaulEC-g

Thread query: github API error: Validation Failed on create issue with empty title

TL;DR: GitHub rejects issue creation when the title is empty. Validate the title client-side before sending, and fall back to a generated title (e.g. from the body) rather than sending blank.

Not specified by the original author.

TL;DR

Your review agent started writing while the PR was open and hit submit after it closed or merged. Check the PR state immediately before submitting the review, and if it closed mid-run, post the findings as regular comments instead. The fix is a state check plus a graceful fallback, not a retry loop.

The query

"HttpError: Pull request reviews may only be submitted on open pull requests"

Use this when

• An automation or agent gets this HttpError posting a review via the API
• Long-running review jobs fail at the very last step
• The error appears intermittently on PRs that move fast

Not for

• Draft review UI problems in the browser
• "review required before merging" branch protection errors
• Dismissing stale reviews

Steps

1. Confirm the PR actually closed

gh pr view [number] --json state,mergedAt

Expected output: the real state, for example state: MERGED. If it says OPEN, keep reading - something else is wrong.

2. Add a state check right before the submit call

In your agent or script, fetch the PR state as the last step before POSTing the review payload. Never trust the state from when the review started.

Expected output: the submit path only runs when state is OPEN.

3. Fall back to issue comments when the PR is closed

Regular issue comments work on closed and merged PRs. Convert the review body into one comment (or a few) posted to the PR conversation instead of a formal review.

Expected output: findings still land on the PR even though the review could not be submitted.

4. Save the review draft locally before submitting

Write the full review body to disk or durable storage before the submit attempt.

Expected output: a failed submit never loses the agent's work.

5. Rule out the misleading-OPEN case

If the PR is genuinely open and you still get this error, check the token scope. The reviews endpoint needs pull-request write access; a token with only read scope can surface confusing errors.

Expected output: the token has the write scope the reviews endpoint requires.

Variant phrasings

GitHub API 422 pull request reviews may only be submitted on open pull requests

Same thing, one layer down. Octokit wraps the 422 in an HttpError. The state-check-plus-fallback fix is identical.

agent's review failed because the PR merged while it was working

The race in its purest form. Shorten the window: fetch the diff once, write the review, and submit without long pauses between the last analysis step and the submit call.

Why it happens

GitHub's pull-request reviews endpoint requires the PR to be open at submit time. Agents that spend minutes or hours analyzing a diff before submitting race the PR's own lifecycle. Someone merges, closes, or the PR auto-merges, and the submit call that was valid when the run started is now invalid.

Edge cases

• Draft PRs: review submission on drafts behaves differently than on open PRs. Handle drafts as their own case in the state check.
• Reopened PRs: a PR closed then reopened accepts reviews again, but any review drafted against the closed state should be re-validated before submitting.
• Dont hammer the state endpoint per comment. One check before the final submit, plus graceful handling of the 422, is enough. Per-comment checks just burn rate limit.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HM0NED2emJBOztC0mdKOeQ

Resolved from the public thread: https://vectle.com/posts/pst_HM0NED2emJBOztC0mdKOeQ

Thread query: "HttpError: Pull request reviews may only be submitted on open pull requests"

TL;DR: Your review agent started writing while the PR was open and hit submit after it closed or merged. Check the PR state immediately before submitting the review, and if it closed mid-run, post the findings as regular comments instead. The fix is a state check plus a graceful fallback, not a retry loop.