GitHub integration¶
Core provides scoped native GitHub operations for repositories, Issues, pull requests, comments, reviews, merge checks, Projects and Releases. Use them to connect code changes with verifiable remote outcomes, without giving a task unbounded access to your account.
Configure repository scope¶
Add a GitHub section to the selected Core configuration. Replace these examples with actual account/repository names and apply the configuration deliberately:
[github]
account = "my-account"
read_repositories = ["owner/reference"]
write_repositories = ["owner/project"]
read_owners = []
write_owners = []
attribution = true
Write scope includes reads. Empty scopes grant no repository access. Prefer
exact repository scope to an owner-wide grant. Do not mix legacy repositories
with the explicit read/write forms. Core scope, App resource installation and
GitHub account authorization must all allow the operation.
Connect the native account¶
Ask the assistant to inspect list_integrations, then start one explicitly
authorized connect_integration Device Flow with a saved request ID. Complete
the returned GitHub URL/code yourself, and install/approve the official Open
Machine GitHub App for the intended resources using the returned installation
URL. User identity consent alone does not grant repository access.
Read the original login ID with read_integration_login until its outcome is
known. Core owns the finite login attempt; passive reads do not start another.
No PAT, App private key, client secret or custom App registration is required.
The retired existing_gh backend is not a fallback for current runtime requests.
With the selected absolute CONFIG and STATE, probe the intended repository:
openmachine --config "$CONFIG" --state-dir "$STATE" doctor \
--github --repository owner/project
Check the returned account, repository access and error, not just local saved connection status. Git clone/push authentication is separate from this App connection; Core does not configure a global Git credential helper.
Use the integration¶
Use OpenMachine's native GitHub connection for owner/project. Read the current
repository and open pull requests, then summarize their actual check status.
Do not create, edit, comment, review or merge anything.
For a write, authorize the specific destination and intended effect. A PR workflow normally reads the Issue and source, edits/tests in a workspace, pushes an explicit branch, creates one PR, then reviews its complete current diff/checks/discussion. Merge requires the actual current head/base and all applicable GitHub gates. Neither passing CI nor creating a PR grants merge permission.
Supported operations and boundaries¶
| Area | Supported use |
|---|---|
| Repository/source | Read metadata, branches, exact commits/files, history, releases and checks. |
| Issues / PRs | Create/update, labels and assignees, PR readiness; read back the same destination. |
| Comments / reviews | Top-level comment create/update/delete, review create/update, thread resolve/unresolve with guards. |
| Merge | Checked merge using explicit current head/base; verify the destination commit. |
| Projects | Read supported organization Projects metadata; add an existing Issue/PR and update a supported field. |
| Releases | Create a Release for an existing verified tag with explicit notes; default is draft. |
This is not an arbitrary GitHub API proxy. It does not supply Git push, repository administration, asset upload or unlimited Project mutation through these tools. Pagination and diff truncation must be resolved before review; a partial diff cannot establish that the whole PR is safe.
Verify, disconnect and recover¶
Record original task/operation IDs, account binding, repository and returned Issue/PR/comment IDs. Read the actual destination after writes. An uncertain create or merge is not permission to send a duplicate. A self-review comment is not an independent approval and cannot override branch protection.
disconnect_integration uses the observed authorization revision to disable the
local connection and clean up owned credentials. It is not proof of provider-side
grant revocation; manage GitHub's authorization separately when needed.
Credentials use the pinned native backend (macOS Keychain, otherwise private
files), not your task logs. Reauthorization can be necessary after revocation,
host loss or prolonged offline periods.
Default attribution appends the product's footer to supported new GitHub content; disabling it stops new automatic footers, not removal of existing attribution. See the connection guide and GitHub reference for exact guards, current actions and original-destination recovery.