An assistant working in your editor can use the project folder you opened. A hosted agent starts elsewhere. It needs a repository connection, a working environment, and enough access to carry out its task. That is why signing in successfully can still leave you staring at an empty repository picker.
This guide covers the documented GitHub connection routes for Cursor and Kiro cloud agents, then provides a practical method for evaluating other AI tools. The goal is a completed, reviewable contribution, not merely a successful authorization screen.
Start by identifying the tool's actual capability
“Connect GitHub” can mean several things. A chat connector may retrieve repository content. A local agent may edit a checkout using installed Git tools. A GitHub App may receive events and create pull requests. A cloud development environment may clone, build, test, and publish a branch.
Before connecting, ask which of those operations you need. For explaining code, read access may suffice. For implementing a fix, the agent needs a working copy and execution tools. For opening the result as a pull request, it needs an authorized publication route too.
An MCP server is an interface through which an assistant can call exposed tools. It is not, by itself, a replacement for a checkout, a compiler, or a test environment. Use a vendor-supported connector or server when it supplies capabilities the task actually needs, and inspect what it can read or change before enabling it.
Connect Cursor's cloud agents
Cursor documents cloud agents separately from local editor work. Its GitHub integration guide provides the account-level connection route, including separate GitHub.com and GitHub Enterprise Server paths.
- Have the appropriate Cursor and GitHub administrators establish the connection through Cursor's dashboard Integrations area.
- Choose Connect beside GitHub, or manage an existing connection.
- Authorize the intended repositories. For an initial exercise, selected-repository access makes the scope easy to understand.
- Return to Cursor and configure the relevant repository features.
- Create a cloud environment for the project and inspect setup results before assigning work.
Follow the Server-specific documentation and administrative flow for GitHub Enterprise Server. Do not substitute a private hostname into a GitHub.com app authorization URL. Network connectivity is part of this setup, especially when the server is not publicly reachable.
Cursor's cloud environment guide describes selecting repositories, supplying needed environment configuration, and preparing the environment so the agent can run the project. For a README change, extensive application setup may be unnecessary. For a functional change, dependencies and test execution are central to whether the result is credible.
Start the task from Cursor's documented cloud-agent surface, select the prepared repository environment, and provide a bounded request. Inspect the agent's branch and proposed changes before accepting the handoff. The cloud-agent overview explains the separate execution environment and supported entry points.
Connect Kiro Web
Kiro's Web setup guide distinguishes sign-in from repository-provider authorization. After signing in with an eligible account and completing any organization enablement:
- Open Settings and select the Agent tab.
- Choose Connect GitHub.
- Authorize the Kiro Agent GitHub app.
- Select the repositories the agent should access.
- Start a session with the intended repository and a clearly defined task.
The repository must be accessible both to your user and to the installed app. Write permission is required for the documented branch and pull-request workflow. An organization repository missing from the picker often calls for reviewing app installation scope or owner approval, not repeating personal sign-in.
These steps describe the documented Web connection. They are not evidence that every private Enterprise Server deployment is supported by the same route. Verify host support and network requirements before making a hosted connection part of an enterprise procedure. The local IDE can still use an approved local checkout independently of that decision.
Use a task that tests the whole connection
For the first task, ask the agent to clarify a README download section. Provide the exact repository and starting branch, and use acceptance criteria such as these:
Improve the existing README download instructions for first-time users.
Use the repository's established distribution route and actual links.
Explain source archives versus installable assets only where applicable.
Change only README.md. Do not create releases, change workflows, or add
new distribution files. If the intended download cannot be verified,
report the missing evidence instead of inventing instructions.
Prepare a contribution branch and show the diff. Check Markdown and links
where the environment permits. Report checks performed and checks blocked.
Leave the result ready for human review; do not merge it.The expected result is a branch with the intended paragraph change and enough evidence for a reviewer to evaluate it. A task that produces only prose in chat has not demonstrated repository editing. A task that changes files but cannot publish has not demonstrated the full remote workflow. Both can be useful intermediate results, but name them accurately.
These are illustrative verification criteria, not results from a live integration test performed for this article.
Evaluate other AI tools with the same sequence
For another product, follow its official connection instructions and answer five concrete questions before treating setup as complete:
| Question | Evidence to look for |
|---|---|
| Which identity is connected? | Correct user, organization, and repository host |
| What can the integration access? | Explicit repository selection and granted operations |
| Where does work execute? | Local checkout, hosted environment, or managed runner |
| Can it verify the change? | Available runtimes, dependencies, and actual check output |
| How is work handed back? | Inspectable files, branch, commit, or pull request |
For a chat-only connector, ask it to read a named file and cite the location before assuming write capability. For an IDE extension, prove it sees the correct local folder. For a GitHub App, inspect its installation scope. For a hosted agent, confirm the environment can obtain the dependencies relevant to the task.
The most common setup failures become easier to diagnose this way. An empty picker points toward identity or app scope. A clone timeout points toward connectivity or credentials. A missing test command points toward environment setup. A rejected push points toward write permission, branch rules, or the chosen destination.
Keep the connection useful after the first task
Record the supported host, repository scope, environment setup, and review workflow in the team's onboarding documentation. Revisit those instructions when the tool or repository changes. A working connection can become incomplete when a project adopts a private package registry, changes its test command, or adds another repository dependency.
A cloud agent earns its place in the workflow by returning changes that the team can understand and verify. Treat connection setup as the first small demonstration of that ability, and make the next task larger only when the evidence supports it.