Skip to content

Suggest a change back

Someone shared a repo and you spotted a fix — a typo, a better wording, a bug. This is how you send your edit back so the owner can review it and, if they like it, fold it in. Your version sits side by side with the original until they say yes; you never overwrite their work.

Time: ~2–5 min for a small edit. The owner approving it is on them, not you. You'll need: a GitHub account (free), and the repo open in your browser or on your machine. Last verified: 2026-06-07 · works the same on macOS, Windows, and Linux.

New to all this? The browser path below needs nothing but a GitHub account — start there.

What's actually happening

GitHub calls this a pull request (PR). The name is backwards-sounding: you're not pulling anything, you're offering a change. Picture it as a tracked suggestion — like "suggesting" mode in a shared doc, but for code or files. The owner sees exactly what you changed, line by line, and clicks to accept or decline. [confirmed]

You don't need permission to suggest. GitHub makes you your own copy of the repo behind the scenes (a "fork"), puts your edit there, and links it back as a proposal. The owner's original is untouched until they merge. [confirmed]

The default: ask your agent

If you have the repo on your machine and Claude Code running with the GitHub CLI connected, make your edit, then say:

"Open a pull request with this change back to the original project. Make a fork if I don't have write access, and fill in a clear title and description from my edit."

Your agent commits the change, creates the fork if it needs one, pushes, and opens the PR — printing the link at the end. The CLI auto-forks when you can't push directly, so the same sentence works whether you own the repo or not. [confirmed]

Send that link to the owner. That's the whole job.

By hand, in the browser (no install, no agent)

The simplest path for a one-line fix — GitHub does the forking for you:

  1. Open the file on the repo's web page and click the pencil icon (top-right of the file).
  2. GitHub says you don't have write access and offers to fork the repository — click it. (This is just GitHub making your own copy; nothing happens to the original.)
  3. Make your edit, then click Commit changes….
  4. Write a one-line note on what you changed, leave "Propose changes" selected, and click Propose changes. [confirmed]
  5. On the next screen, add a title and a sentence of context, then click Create pull request. [confirmed]

The owner now gets a notification with your change laid out for review. Copy the page URL and message them too, so it doesn't sit unseen.

For more than a quick edit — several files, testing your change first — fork the repo, edit your copy, then open the PR from it: GitHub's create-a-PR-from-a-fork guide. [confirmed]

You're done when

The repo's Pull requests tab shows your proposal, open, with your changes as green/red lines. The owner can comment, request tweaks, or merge it. If they ask for a change, edit the same file again the same way — your PR updates itself, no need to start over. [confirmed]

If it doesn't work

  • No "Create pull request" button, or it's greyed out → you've changed nothing yet, or you're comparing a branch to itself. Make sure your edit is saved and that the "base" is the original project, the "compare" is your copy.
  • "You must have write access" / the pencil does nothing → you're not signed in, or signed into the wrong account. Log in, reload the file page, and the pencil will offer to fork instead. [confirmed]
  • Agent says "permission denied" pushing → it tried to push straight to a repo you don't own. Tell it: "I don't have write access — fork it first, then open the PR from my fork." The CLI does this automatically when prompted. [confirmed]
  • Your PR shows way more changes than you made → your copy has fallen behind the original. Ask your agent to "update my fork from upstream, then rebuild the PR", or open a fresh PR from an up-to-date copy.
  • Owner never responds → a PR is just an offer; they're under no obligation to take it. Ping them with the link, or — if it's your call — they may have abandoned the project. Nothing you sent affects their repo.
  • Anything else → GitHub's About pull requests covers the full flow with screenshots.

Watch / read

  • Best written walkthrough: GitHub's own Creating a pull request from a fork — the authoritative, current source; covers the "compare across forks" and "Allow edits from maintainers" steps the videos skip.
  • Video: How to create a pull request in 4 min — GitHub (official channel), 3:44. Why this one: it's GitHub's own, so the UI matches what you'll see. Caveat: transcript couldn't be re-verified from this environment — if the menus look different, the written guide above is the source of truth. [unclear — video content not verified here]
  • Video: How To Pull Request in 3 Minutes — Keep On Coding, 3:06. Why this one: tightly scoped to exactly this task, no filler. Same caveat — okay start, lean on the written guide if it drifts. [unclear — video content not verified here]

Sources