Skip to main content
The GitHub connector gives the agent three independent ways to work with GitHub:
  • Tools: GitHub is a tool server integration like Gmail or Linear, so the connector can load LangChain-authored GitHub API tools through LangSmith’s gateway. The provider token stays in LangSmith’s vault.
  • Sandbox: the connector also prepares repositories, the gh CLI, and credentials inside a managed sandbox, so the agent can inspect or change checkouts directly.
  • Events: pass events to receive GitHub App webhooks. Any webhook event can invoke the agent, which can auto-reply as an issue or pull request comment. See Receive GitHub App webhooks.
The GitHub connector requires managed-deepagents>=0.4.0.
Managed Deep Agents is in private beta, available on LangSmith Cloud in the US region only. Join the waitlist to request access.
For user OAuth rather than an App installation, see Connect-with-GitHub under identity.

Add the connector

Create connectors/github.py or connectors/github.ts and export a named connector:
The connector clones each repository when the sandbox is created. When a thread reuses an existing sandbox, on_reuse / onReuse controls the checkout (see Configure options).

Tools and the installCLI rule

The two halves meet in one rule: installCLI decides the default tool surface. With gh in the sandbox (the default), the agent already reaches the GitHub API, so the integration’s tool definitions stay off. Adding them would be a second route to the same endpoints. Naming tools with include_tools / includeTools, or setting installCLI: false, turns them on. An explicit selection always wins, including exclude_tools / excludeTools on its own. A checkout-only project needs no tool config and no connected GitHub integration in the workspace, because the gateway is never called:
Tool names are provider-qualified (github_create_pull_request), not prefixed. For how the gateway resolves credentials, see Tool server integrations.

Configure options

Each entry in repositories accepts these fields: Set write to true only on checkouts the agent must push to, since it grants write credentials for the repository. Leave it unset for read-only work. For private repositories, configure GitHub credentials through identity. The runtime resolves the credential, injects it into the sandbox as GH_TOKEN, and configures Git credentials for the run. The token is never stored in thread state.

Receive GitHub App webhooks

Pass events to let a GitHub App send webhooks to the agent. The connector name becomes the ingress path (githubPOST /connectors/github/events). The runtime verifies signatures, runs the agent, and can auto-reply as a pull request or issue comment. Webhook ingress requires a root identity declaration. Each entry in events is an ordered handler: the first match for a delivery wins. Each needs on and a prompt callback that builds the human message for that turn. The agent system prompt remains instructions.md.
Pair webhook events with an identity scope that does not require a human caller. The event user is the installation or service principal github-app:<installationId>, not the pull request author. Replies use the App installation token; Connect-with-GitHub OAuth is not required for this path.

Event filters (on)

Any GitHub webhook event is accepted. Filter with on: Managed Deep Agents does not ship copies of GitHub webhook payload schemas. The envelope passes common routing fields (eventName / event_name, action, repository, issueOrPullNumber / issue_or_pull_number, …) and leaves the verified JSON on payload as untyped. In TypeScript, narrow with @octokit/webhooks-types. In Python, narrow with your own TypedDicts or runtime checks.

prompt vs instructions.md

How GitHub webhooks work

  1. GitHub POSTs to https://<agent-server>/connectors/github/events (the connector name becomes the path segment).
  2. The runtime verifies X-Hub-Signature-256 against GITHUB_WEBHOOK_SECRET, dedupes on X-GitHub-Delivery, and returns HTTP 202.
  3. It picks the first matching handler, calls prompt to build the inbound text, then invokes the graph over trusted loopback with user and source-thread identity (source.provider: "github").
  4. When the matched handler has autoReply enabled and the conversation address is owner/repo#N, it posts the agent response as an issue/PR comment with the App installation token. Events without an issue/PR number skip the comment even when autoReply is true.
LangGraph auth is bypassed only on POST /connectors/{name}/events so GitHub can deliver without an ingress secret; the loopback invoke still uses MDA_INGRESS_SECRET.

Event handler options

Compile extracts only { on, repositories, autoReply } into the deploy manifest. Live prompt callbacks stay on the imported connector module.

Required webhook secrets

Put these in the project .env (or LangSmith workspace secrets) before mda deploy. Deploy preflights the connector’s requiredEnv from the compiled manifest.

Configure the GitHub App

  1. Create a GitHub App (or reuse one you control) with permissions implied by your handlers (at minimum metadata:read; issues:write and pull_requests:read when any handler has autoReply enabled). Tighten App permissions in GitHub settings to match what you actually use.
  2. Subscribe the App to the webhook events your handlers need (for example Pull request for pull_request.opened, or broader events if you use "*" / event-level filters).
  3. Set the webhook URL to https://<agent-server>/connectors/github/events and configure the webhook secret as GITHUB_WEBHOOK_SECRET.
  4. Install the App on the target org or repositories and copy the installation id into GITHUB_INSTALLATION_ID.
  5. Copy the App id and private key into GITHUB_APP_ID and GITHUB_APP_PRIVATE_KEY.

Test and deploy

Test the project locally with mda dev, then deploy it with mda deploy. Open deployment traces in LangSmith to inspect model calls, tool calls, errors, and latency. The sandbox half runs only when the project declares a managed sandbox; without one, it does not run. After startup, confirm the checkout by asking the agent to list the files at the configured path, and confirm credentials by asking it to run gh auth status in the sandbox. When you use events, trigger a matching webhook (for example open a pull request on an allowed repository) and confirm the agent run appears in LangSmith, along with an issue/PR comment when autoReply is true and the event has an issue/PR number. For deploy symptoms and fixes, see Troubleshooting.

Webhook troubleshooting

Next steps

Connectors

Compare connector types.

Tool server integrations

See how LangSmith-hosted integration tools reach the agent.

Identity

Scope callers and resolve credentials.

Configure a sandbox

Configure sandbox scope and lifecycle.