How to Use the GitHub Connector in Muse

1. The short answer

As of October 25, 2026, GitHub is a live connector in Muse. Connect it and Muse can read your code repositories, explain what the code does, triage your issues, review a pull request, and draft your release notes. That is the short answer, and it matters because the hardest part of working in a codebase is not writing code. It is understanding code someone else wrote, and the connector turns that understanding into a question you can ask in plain words.

GitHub went live on September 29, 2026, and it was confirmed in the October 7, 2026 App Store release notes and named in the October 7 expanded connector list. Across Muse as a whole, an in app check on October 15 counted 54 connectors live in the web app, with about 58 to 60 live in total including phone only features, and 18 announced but not yet live. Our full connectors list keeps the dated picture for every connector, so check there before you plan a workflow around any single one.

Here is the honest version. GitHub is where the code lives, and Muse is where the code gets explained. The safe bet is the reading half: Muse can summarize a repository you did not write, walk you through a feature, sort an issue pile into what matters and what can wait, and read a pull request before you merge it. The open question is the writing half. Meta has not published whether Muse can merge a pull request, close an issue, push a change, or create a branch, so nobody outside Meta can say for certain what happens inside GitHub itself. Use Muse to read and review, make the changes yourself, and test the boundary before you promise anyone a hands free coding workflow.

Muse is invite only right now. Need an invite code? Click here to grab one free from the community pool. Waiting on a launch in your country? Join the waitlist and we will send you a fresh code on launch day. Muse is available in the United States, Canada, and Japan.

2. What you need

• Muse access. You need an account with access first, in the United States, Canada, or Japan, where Muse has launched.
• A GitHub account with access to the repository. The connector reads the repositories your GitHub account can open, so sign in with the account that actually has access. A private repository your account cannot open is invisible to Muse.
• Your GitHub sign in. You connect with your GitHub account, the same way you sign in to GitHub itself. Connect through the official connector flow, and never paste a personal access token into a chat.
• Approvals set to ask me. Before you connect anything that touches code, set approvals so nothing is merged, closed, or pushed without your tap. This is the single most important step on this page.
• The question you actually need answered. What does this repository do, where does this feature live, which issues are blocking the release. A repository without a question is a tour, and a tour is the slowest way to get an answer.
• A test run before every merge. A review from Muse is not a test run. Keep your own tests as the gate, and let Muse be the second pair of eyes, not the only one.

3. How to connect it, step by step

The connection itself takes a few minutes. The setup around it matters more, because a repository is shared work and a wrong merge touches other people. Run the steps in order and do not skip the approvals step at the end.

1. Open Muse and go to Settings. The connectors list lives there. What is printed there is what your account has, because rollout is staged and two accounts can see different lists on the same day.
2. Find GitHub in the connectors list and open it. If GitHub is not listed, your account has not received it yet. There is nothing to install and nothing you broke. Check again in a few days.
3. Sign in with GitHub. Use the account that has access to the repositories you want Muse to read. If you have a personal GitHub account and a work one, pick the one that holds the code you actually work on.
4. Grant the access Muse asks for. Muse needs permission to read your repositories. Read the permission screen before you accept it, and check which repositories you granted. If a scope surprises you, stop and check what it covers before continuing.
5. Set approvals to ask me. In Muse settings, set approvals so that anything that merges, closes, pushes, or deletes always waits for you. This is what stops Muse from ever changing your code without your say.
6. Test with a read only request. Ask Muse to describe one repository in a paragraph and list its open issues. Read the answer against GitHub. If it matches, the connection is good. Do not ask it to change anything on the first day.
7. Use it read only for a week. Summaries, explanations, issue triage, and pull request reviews only. Once you trust what it reads, test one small writing step if you need it, and watch exactly what it does before you trust a second one.

Copy this prompt

You are my code review assistant. Use my GitHub connector only.
Rules: you never merge, close, push, or delete anything in GitHub without my explicit approval. You read, summarize, explain, and review. I approve every change.
My repository: [the name of the repository, and what it does]
My project: [what the product does, who uses it]
Do this in order.
1. Summarize the repository in one paragraph: what it does and how it is organized.
2. List the open issues, grouped by what blocks the next release and what can wait.
3. For the pull request I name, review it: what it changes, what could break, and what to check before merging.
4. Find where the feature I name lives in the code, and explain how it works in plain words.
5. Draft the release notes for the next release, based on the merged pull requests.
6. End with the 3 things I should look at first, in order.

4. What it actually does

The connector earns its place with six uses. All six are reads and reviews, and they are the ones to build a habit around. If Muse can also write to GitHub, that is a bonus you test later, not the reason you connect it today.

Get oriented in a repository you did not write

Ask Muse to describe a repository in one paragraph: what it does, how it is organized, and where the important parts live. This is the use that saves the most time, because joining a codebase is mostly reading, and reading a whole repository takes days. A new teammate, a returning founder, or a contractor who needs to fix one bug all need the same thing, and it is a map, not a tour. The map should name the parts of the code that carry the product and the parts that are dead weight, because the dead weight is where the next confusion lives. Keep the summaries and compare them over time, because a repository whose summary keeps changing is a product whose shape keeps moving, and that is worth knowing before the next planning meeting.

Triage the issue pile

Ask Muse to sort your open issues into what blocks the next release, what can wait, and what is probably already fixed or no longer relevant. This is the use that turns an issue pile into a morning of work. The pile grows quietly, one report at a time, and after a few months nobody knows which issues still matter. The rule is that every grouping traces back to something written in the issue itself, and anything Muse guessed gets flagged as a guess, not as a fact. A triage that mixes issue words with assistant guesses is a triage that closes the wrong issues, and the fix for that is to check each grouping against the issue before you act on it. Run the triage weekly and the pile stops growing, because the issues you close each week are the ones that would have buried the release.

Review a pull request before you merge

Ask Muse to review a pull request: what it changes, what could break, and what to check before merging. This is different from reading the diff yourself, because Muse tells you the intent of the change in words, and intent is what you argue about in a review. The question to ask is what could break: the edge case the author missed, the dependency that changed, the test that does not cover the new path. A review from Muse is a second pair of eyes, and a second pair of eyes is worth the most on the pull request you were about to merge in a hurry. The limit is absolute. A review is not a test run. Run your tests before you merge, every single time, because a review that sounds confident and a test suite that passes are two different kinds of proof, and only one of them runs the code.

Draft release notes and changelogs

Ask Muse to draft the release notes from the pull requests merged since the last release, grouped by what is new, what is fixed, and what changed under the hood. This is the use that kills the blank page at release time, because release notes are always written last, in a hurry, by the person who least wants to write them. The draft should be specific enough that a user can tell whether the release matters to them, and short enough that they actually read it. Read every line before it goes out, because a release note that promises a fix you did not ship is a promise your users will hold you to, and a changelog that lists the wrong version is a changelog nobody trusts twice.

Find where a feature lives

Ask Muse where a feature lives in the code, and how it works in plain words. This is the question you ask when a bug report lands and nobody remembers which part of the code owns the behavior. The answer should name the files and the flow: the entry point, the logic, and the place where the result comes out. The follow up question matters more than the first one. Ask what else touches the same code, because a fix in one place breaks another place that shared the same helper, and the shared helper is the thing nobody remembers. A feature you can find is a bug you can fix, and a feature you cannot find is a bug that stays open while the team argues about where to look.

Onboard a new contributor

Ask Muse to write the tour for a new contributor: how to set the project up, where the important code lives, how a change goes from an idea to a merged pull request, and what the unwritten rules are. This is the use that turns a week of shoulder tapping into a document the new person can read alone. The tour should be honest about the rough edges, because a tour that pretends the setup is smooth is a tour that wastes the new person a day. Send the tour, not the chat. Copy the tour out of Muse and keep it in the repository, because a document in the repository is a document the next person finds, and a chat transcript is a document nobody finds twice.

5. What it cannot do

The limits are honest and worth knowing before you lean on the connector.

• It cannot be relied on to write to GitHub until you have seen it do so. Merging a pull request, closing an issue, pushing a change, and creating a branch are writing actions, and Meta has not published whether Muse can take them. Test one small writing step with approvals on ask me and watch what it does before you trust a second one.
• It cannot see repositories your account cannot open. Private repositories nobody shared with your GitHub account, repositories in another organization, and code in a personal account you did not connect are invisible to it. It reasons from what your account can open, nothing more.
• It cannot run your tests. A review from Muse reads the code. It does not run the code. Run your tests before you merge, every single time, because a confident review and a passing test suite are two different kinds of proof.
• It cannot guarantee a review catches every bug. A review can miss a problem, and a summary can misread a feature. Check anything that touches production, money, or user data against the code itself before you act on it.
• It cannot fix a secret that leaked into a repository. If Muse spots a token or a password in the code, treat it as exposed and rotate it at once. A spotted secret is still a leaked secret, and no review undoes the leak.
• It cannot fix a messy repository. If the code is a pile of dead files with no structure, Muse will summarize the pile. Cleaning up the dead code first makes every answer after it dramatically better.

6. What to watch for

As of October 25, 2026, GitHub is a settled connector: live since September 29, confirmed in the October 7 App Store release notes, named in the October 7 expanded list, and still on the list in the October 15 in app check. There is no October update to how it works, so the habits around it matter more than the news. Check every review against the code for the first week, especially any claim about what a change does. A wrong read acted on fast is worse than a slow read you verified.

Be careful with shared repositories. A repository is shared work, and a merge touches other people. Keep anything that merges, closes, pushes, or deletes on ask me, and keep it there even after you trust the loop. The failure mode you want is a review waiting for you, not a merge already done. If Muse ever offers to change code you did not ask it to change, say no and check what it was trying to do. A connector that touches code deserves more caution than one that reads your notes, not less.

Elsewhere on the list, PayPal was announced on September 22 and its October live status is unverified, so do not plan a workflow around it yet. Amazon has no connector and none is expected. If a tool you need is not on the list at all, ask Muse to build a custom connector: any service with a public API can be connected that way, and Meta does not review custom connectors. Our connectors list keeps the dated status for all of these, so check there before you build on any single claim.

Finally, check your data controls. In Muse settings, open Data controls and look at the switch for helping improve the models. If you do not want your chats used for training, turn it off before you start asking Muse to read your code. Private code deserves that decision made deliberately, not discovered later, and a token pasted into a chat is a token you should rotate at once.

Get started

Frequently asked questions

Can Muse merge a pull request?

That is the honest gap in this guide. Meta has not published whether Muse can merge pull requests or close issues in GitHub, so use Muse to review first, and test one small writing step yourself. Do not promise anyone a hands free merge workflow until you have seen it work.

Can Muse see my private repositories?

Only the repositories your connected GitHub account can open. Check which repositories you granted when you connected, because a private repository nobody shared with that account is invisible to Muse.

Can Muse write code in my repository?

Muse can draft code in the chat, and that is the safe use. Whether the connector can write that code into your repository is unverified, so treat writing into the repository as a separate step you control yourself.

Does it work with GitHub Issues and Projects?

Issues are the core use: triage, summaries, and reviews all start from issues. Whether the connector also covers GitHub Projects boards is unverified, so ask Muse what it can see and check the answer before you plan around Projects.

Can I use the GitHub connector outside the United States, Canada, and Japan?

Not yet. Muse itself has launched in the United States, Canada, and Japan only. Join the waitlist and we will send you a fresh code on launch day in your country.

What happens if I disconnect GitHub?

Muse loses access to your repositories. Your code stays on GitHub, and nothing Muse drafted is merged or changed after you disconnect. You can reconnect the same account or a different one later.

Built with Muse is an independent community project. Not affiliated with or endorsed by Meta.