Get Notified When an Autonomous Coding Agent Opens a PR
Ping your phone the moment an autonomous coding agent opens a PR: a GitHub Actions step or a one-line curl. Setup takes 5 minutes.

You handed the agent a ticket and went to lunch. Forty minutes later it had written the code, pushed a branch, and opened a pull request, which has been sitting there, waiting for your review, ever since. You just don't know it yet.
Autonomous coding agents (Claude Code on a long task, Codex, Devin, a Cursor background agent), now run unattended and finish the same way a teammate would: by opening a PR. That's the moment the work is actually ready for you. But GitHub tells you about it the way it tells you about everything else. An email in a pile of emails. A red badge you'll notice eventually.
"Eventually" is the whole problem. The point of an agent working while you're away is that you're away, not refreshing the pull requests tab every five minutes. A push to your phone the instant a PR opens closes that gap, so you review it while it's fresh instead of three hours later.
There are two ways to wire it up, depending on how your agent runs: a GitHub Actions step if it opens PRs on GitHub's side, or a one-line curl if it runs in your terminal. Both come down to a single HTTP POST to TheNotificationApp the moment a pull request appears, no new dashboard to babysit.
The cleanest version: a GitHub Actions step
GitHub already knows the exact second a PR opens, so let it do the work. Drop this in .github/workflows/pr-alert.yml and it runs on every new pull request:
name: PR opened alert
on:
pull_request:
types: [opened]
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Ping my phone
env:
PR_TITLE: ${{ github.event.pull_request.title }}
PR_AUTHOR: ${{ github.event.pull_request.user.login }}
PR_URL: ${{ github.event.pull_request.html_url }}
APP_KEY: ${{ secrets.NOTIFICATION_APP_KEY }}
run: |
curl -s -X POST https://thenotification.app/api/sendNotification \
-H "app_key: $APP_KEY" \
-H "Content-Type: application/json" \
-d "$(jq -n \
--arg title "🤖 $PR_AUTHOR opened a PR" \
--arg body "$PR_TITLE" \
--arg link "$PR_URL" \
'{title: $title, body: $body, link: $link}')"
Add your API key under Settings → Secrets and variables → Actions as NOTIFICATION_APP_KEY. The jq call builds the JSON for you, so a PR title with quotes, backticks, or an emoji won't break the request: a mistake you'd absolutely make hand-rolling the JSON string. Tap the notification and you land straight on the PR.
Only ping me when it's a bot: not me
You don't want a buzz for your own PRs. The fix is one line, an if: filter on the step. A lot of agents (Copilot, Devin, a GitHub App) open PRs from a bot account, so you can gate on the author type:
if: github.event.pull_request.user.type == 'Bot'
Running an agent under your own token instead? Then the PR opens as you, and the bot check won't catch it. Filter on the branch name the agent uses: Claude Code and most agents prefix theirs, so match that:
if: startsWith(github.head_ref, 'claude/') && github.event.pull_request.draft == false
That second condition matters more than it looks: types: [opened] fires for draft PRs too, and agents love opening drafts. Gate on draft == false and you only hear about the ones that are genuinely ready for review.
Driving the agent yourself? It's one line
Some agents run right in your terminal and open the PR with the GitHub CLI. If that's your setup, skip Actions entirely and chain the notification onto the same command. It only fires if gh pr create actually succeeds:
gh pr create --fill && URL=$(gh pr view --json url -q .url) && \
curl -s -X POST https://thenotification.app/api/sendNotification \
-H "app_key: $NOTIFICATION_APP_KEY" \
-H "Content-Type: application/json" \
-d "{\"title\":\"🤖 Agent opened a PR\",\"body\":\"Ready for review\",\"link\":\"$URL\"}"
The gh pr view call hands back a plain URL, so it drops straight into the JSON without any escaping drama. Same idea as sending yourself a ping when any long agent run finishes: you're just moving the trigger to the exact moment a PR exists. The full list of body fields lives in the curl docs, and if you already have GitHub push notifications on your iPhone set up, this slots right alongside them.
Put something worth reading in the ping
A notification that just says "new PR" makes you open your laptop to find out if it's worth opening your laptop. Skip that. Put the author in the title and the PR title in the body (the Actions example above already does), so a glance tells you whether it's the refactor you were waiting on or a one-line dependency bump that can wait until morning. The link field makes the whole thing tappable, straight to the diff.
The real talk
Fair warning about the count: the free tier is 100 notifications total, not per month, total. On a busy repo where an agent opens a dozen PRs a day, that's gone inside a week. Keep the bot-or-branch filter tight so you're only pinged for the PRs you actually care about. If you outgrow it, Pro is $2.99/month for 1,000 notifications a month, which is a lot of PRs.
Set it up once and the dead time between "the agent opened a PR" and "you noticed" basically disappears. Worth a look if your agents keep finishing while you're looking the other way, thenotification.app.
New to this? Start with what an MCP server is.



