How to connect GitHub to Hermes Agent

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.

Reconnect GitHub from the dashboard, then start a fresh chat if the runtime still has the old tool catalog loaded.

GitHub tool schemas load on demand the first time a tool runs and are cached after that, so this error usually clears on its own: wait a few seconds and retry the same request. If every GitHub call keeps failing with it in a fresh chat, reconnect from the dashboard, and contact support if it still persists — that pattern points to a configuration problem on our side, not something you can fix by reconnecting again.

Two usual causes. The connected account may not have access to the specific workspace, inbox, store, or project in the request — check that first. If access looks right, the agent may have sent a placeholder value (like "YOUR_ID" or an example id from documentation) instead of a real one: ask it to run a list or search tool first, then retry the action with a real id from those results. Most failures at this stage are one of these two, not ClawLink bugs.

Search results answer this with GitHub App permission surgery: the app is not installed on the repository, request the missing permission and reinstall. That is the right fix for a GitHub App and the wrong fix here, because this connection is a user OAuth grant with no installation to adjust. Three things cause it instead. The first is organization approval: many organizations require an owner to approve third-party OAuth applications, and until that happens org-owned repositories return 404 rather than 403, because GitHub hides private resources it will not let you see. That 404-instead-of-403 behaviour is deliberate on GitHub's part and it makes the failure look like a typo. The second is plain access: the connection acts as you, so a repository you were never added to stays unreachable. The third is a placeholder argument, where the agent invents an owner or repo string such as your-org, and the call reaches GitHub and comes back as missing. List first with github_list_repositories_for_the_authenticated_user, then retry with a real full name.

Ask the agent to diagnose it:

Run github_get_the_authenticated_user and tell me which GitHub account is connected. Then run github_list_repositories_for_the_authenticated_user and show me whether the repository I asked about is in the list. Do not retry the failing call until both have returned.

GitHub applies two different limits and they need different responses. The primary rate limit is a request budget over a window, and the response carries headers telling you when it resets; waiting for the reset is the only fix. Secondary rate limits are separate and trigger on bursts of writes or expensive queries, and they can fire well inside the primary budget. An agent looping over hundreds of files, or opening many issues in sequence, hits the secondary limit first. The response often includes a Retry-After value, which is the interval to respect. Reconnecting changes nothing for either one. What does help is changing the shape of the work: ask for search calls instead of enumerate-everything calls, and batch related edits into a single commit rather than one call per file.

Ask the agent to diagnose it:

Report the exact status code and response headers from the failed GitHub call, including any x-ratelimit-reset or Retry-After values. Do not retry it.

With 846 tools in this integration, schemas load on demand rather than all at once, so the first GitHub call in a fresh session can arrive before the catalog does. Retrying once normally resolves it. If the same name fails twice, the name is wrong rather than missing, and the error message lists the closest real tools; retrying with one of those works. Search results for this phrase describe a different world entirely, where an MCP server is missing from claude_desktop_config.json or a server name breaks a length limit. There is no local server and no config file in this setup, so none of those fixes apply.

Ask the agent to diagnose it:

List the GitHub tools you actually have access to that relate to what I asked for, then use the closest exact name.

Try reconnecting GitHub and complete the consent flow in the same browser session. Partial OAuth approvals or switching accounts mid-flow can leave the connection incomplete.

Yes. ClawLink is the fastest way to connect Hermes to GitHub: link your GitHub account once in the browser and Hermes Agent can call the GitHub API through 846 ready-made tools — no custom code or token handling.

Install the plugin with hermes plugins install ClawLink-HQ/hermes-plugin --enable, then pair once: run hermes clawlink begin, approve the link in your browser, and run hermes clawlink finish. Connect GitHub in the dashboard and Hermes can use it from the next message — no config files or API keys to manage.

About two minutes. Sign in, click Connect next to GitHub in the dashboard, authenticate, and Hermes Agent can use it from the next chat message.

The alternative to ClawLink is usually manual OAuth app setup plus your own token handling, permission troubleshooting, and tool plumbing for Hermes Agent. That is fine if you want to build and maintain the integration yourself. Most teams just want GitHub working from chat.

Yes, and the difference is in what the credential can do when it leaks rather than in what it can do when it works. A classic personal access token carries whatever scopes you gave it across everything your account can reach, and it keeps working until you remember to revoke it. A fine-grained token narrows that, which is why GitHub recommends them, but it is still a string you store and renew. This connection is an OAuth grant instead: nothing is written to disk on your side, GitHub lists the authorization in your account settings, and revoking it there ends the agent's access immediately without you hunting for where the token was saved.

The ones your GitHub account can already reach, subject to what you approved during sign-in. This is delegated access, so the agent inherits your permissions rather than receiving its own. A private repository in an organization you do not belong to is invisible to it. Organization policy can also restrict it further: many organizations require an owner to approve third-party OAuth applications before members can use them against org-owned repositories, and until that approval exists the agent will see your personal repositories and none of the organization's. Ask the agent to run github_list_repositories_for_the_authenticated_user and read the list back if you want to know exactly where you stand.

The honest answer separates two risks that usually get discussed as one. The credential risk is the smaller one here, and it is the one this connection improves: no token file exists on your machine to leak, the grant is visible in your GitHub settings, and revocation is immediate and does not depend on us. The behavioural risk is real and is not solved by any connection model: an agent that reads an issue, a pull request comment, or a README is reading text written by other people, and that text can contain instructions aimed at the agent. Treat write actions accordingly. Ask for drafts before pushes, keep branch protection on anything that matters, and remember that the agent acting as you means its commits carry your name. Reviewing what it proposes is not paranoia, it is the same review you would give a new contributor.

The connection targets github.com. A self-hosted GitHub Enterprise Server instance behind your own network is not reachable through this flow, and the self-hosted MCP servers that do target it need a token you manage and a network path to the instance.

Pairing is a two-step handshake: run hermes clawlink begin, approve the link in your browser, then run hermes clawlink finish. If you ran finish before approving, or the approval link expired, run hermes clawlink begin again to get a fresh link. Confirm the plugin was installed with --enable, then verify with hermes clawlink test.