GitHub

WeHarness connects to GitHub through the WeHarness GitHub App. It reads only the repositories you select for the app, and it writes only when a person approves a push in a session.

Connect GitHub

Owners and admins connect GitHub. Other roles see the connected repositories.

1. In the sidebar, open Integrations. Select Add account or organization.
2. GitHub asks where to install the app (your personal account or an organization) and which repositories it may access: all of them, or the ones you select.
3. GitHub sends you back to WeHarness. The account appears under Accounts and organizations, and its repositories appear in a moment.

• An organization’s approval. If you are not an owner of the organization, GitHub sends the request to its owners. Integrations says Installation requested until one of them approves it.
• Already installed? If the app is already installed on an account that is not connected to a workspace, select Find installed accounts, then Connect to this workspace. An installation belongs to one workspace at a time.
• Change the repositories. Select Choose repositories beside the account. This opens the app’s settings on GitHub. Use the refresh button to read the list again.
• Disconnect. The disconnect button beside the account ends the connection in WeHarness: repository context from that account stops being readable at once and is then deleted. To stop the app’s access on GitHub as well, uninstall it on GitHub.

The app asks GitHub for these permissions: contents and pull requests (read and write), checks and commit statuses (read), and workflows (read and write, so a pull request can add a CI file). The account or organization that installs the app accepts them on GitHub.

Choose a repository and branch

• In New session, the repository picker lists the connected repositories; type to find one.
• The branch chip shows the repository’s default branch. The branch picker lists branches with the most recent commit first and can be searched. To use a tag or an older branch, type its name and choose Use “…”.
• The session reads the exact commit of that branch and indexes it for search with citations. See Project context.
• To switch branches during a session, use the branch in the session header, type /branch <name>, or ask in the chat (“look at dev”). The new branch is read before WeHarness continues. If the read fails, the session stays on its previous branch.
• Repository text is treated as data, never as instructions to WeHarness.

Push and pull requests

WeHarness never pushes on its own. Only a session whose code comes from GitHub can push. For an uploaded project, download the Patch from Changes instead.

1. When the draft is ready, WeHarness asks to push, or you type /push (optionally with a pull request title). The request shows in the chat with the files it covers.
2. An owner, admin or member (not a viewer) selects Approve and push in the web app. A coding tool or a model cannot approve. The approval covers this exact draft: if the draft changes afterwards, it needs a new approval.
3. WeHarness writes one commit to the session’s own branch (weharness/…) and opens a pull request against the session’s branch. It never merges.
4. While that pull request is open, later pushes from the session go to it. Each one asks for approval again, for its own exact changes.

Pull request status

Type /pr to see the session’s pull request at a glance: its number, state, branch and base, checks and link, and what changed in the draft since the push. When there are changes not pushed yet (or no pull request yet), /pr asks WeHarness to prepare the push; you approve it as always.

After a push:

• The session header shows where the draft went, for example main → weharness/… · PR #1, linked to the pull request, with its state. When the session reads its own push branch, the header shows weharness/… · PR #1 into main, and the session keeps its pull request.
• The session’s status in the sidebar reads PR #1 open, then merged or closed.
• The branch picker lists the pushed branch.
• Changes says when and where the draft was pushed, and marks each file pushed or new since push. What you change after a push is the draft for the next push.

Review comments

When someone the repository trusts (an owner, a member or a collaborator) comments on the session’s pull request, reviews it with comments, or comments on a line, the comment appears in the session. You see who wrote it, where it points and what it says. Reply in the session and WeHarness takes the comment into account.

What else happens is set per project in Evaluations → Merge gate → Review comments, by an owner or admin:

Mode	What happens
Off	The comment is shown.
Observe (default)	The comment is shown, with a note when auto mode would have started on it.
Auto	WeHarness starts working on the comment in the session, unless it is already working there. This uses the workspace’s credits.

In auto mode, when WeHarness has worked on a comment it answers in the comment’s own thread on GitHub (under a line comment, or in the pull request’s conversation), with a link to the session. You can also list who may start this work (GitHub logins); comments from others are still shown in the session. When the pull request is merged or closed, WeHarness stops any work still running in its sessions; the sessions stay.

• Edited comments, comments by bots, and comments by people outside the repository are not shown.
• An approval without words does not appear.
• The comment’s words are treated as information about the pull request, not as instructions to WeHarness.

This needs the WeHarness GitHub App’s review events, which your organization accepts when the App asks for them.

CI checks

If the repository has CI (for example GitHub Actions), its checks run on the pull request. WeHarness watches them for up to 30 minutes and shows them in the PR tab. /checks asks WeHarness to read them and explain a failure. When a check fails, WeHarness says so in the chat and offers a fix. Without CI, WeHarness can add a workflow file to the pull request, or give you the commands to run.

Deleting a session in WeHarness does not delete a pull request already on GitHub. See Deleting a project.