> ## Documentation Index
> Fetch the complete documentation index at: https://docs.komodor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# GitHub Agent

> Finds the repository files behind a problem an investigation has already characterised, and recommends the durable code change that stops it recurring.

Deploy this agent when an investigation has told you what is failing and the next question is where
in the code it lives. It searches repositories for the evidence's own strings, confirms candidates
by opening them, and returns a ranked shortlist with the fix that shortlist supports. This page
covers what it needs, what makes a good request, and where it stops.

## What it does

You give it a characterised problem — an incident, an error message, a failing service. It searches
code for the error's own text, opens every candidate to confirm it rather than trusting the search
ranking, and checks what changed there just before the problem started.

What comes back is a ranked shortlist of files with the evidence for each, and the durable code
change that shortlist points to.

<Note>
  It runs on concrete evidence. Given a vague problem statement with no error text, no service and no
  timeframe, there is nothing distinctive to search for — so pass it the output of an investigation
  rather than the original alert.
</Note>

## What it reads

| Source          | What it uses it for                                                       |
| --------------- | ------------------------------------------------------------------------- |
| Repository code | Searching for the error's strings, and opening candidates to confirm them |
| File contents   | Reading the surrounding implementation before recommending a change       |
| Recent history  | What changed in a candidate file just before the problem appeared         |

Read access only. It never writes to a repository.

## Before you deploy

| Requirement       | Detail                                                | Where to set it up                                                       |
| ----------------- | ----------------------------------------------------- | ------------------------------------------------------------------------ |
| Model access      | The managed model gateway, or your own Claude API key | [Credentials & secrets](/manage-your-agents/build/credentials-secrets)   |
| GitHub connection | Read access to the repositories it searches           | [Built-in integrations](/manage-your-agents/build/built-in-integrations) |

The GitHub connection is required, and it gates the only path this agent has to GitHub. Without one
it cannot search anything at all — it fails closed and says so, rather than returning an empty
result that reads like "nothing found".

<Note>
  This agent is enabled per workspace. If it is not in your catalog, an account administrator can
  request it for your account.
</Note>

## Ask it for

In chat, or as a run's prompt:

```text theme={null}
Our checkout service is throwing "connection pool exhausted while acquiring lease"
under load since the 14:00 UTC deploy. Find where that message comes from, what
governs the pool size, and what changed there recently.
```

The more of the investigation you pass through — the exact error text, the service, the window —
the narrower its search, and the better the shortlist.

## Defaults and limits

|             |                                        |
| ----------- | -------------------------------------- |
| Catalog ID  | `github-file-finder`                   |
| Model       | `claude-sonnet-5`                      |
| Time budget | 300 seconds, adjustable 60–900 per run |
| Deployment  | Komodor cloud                          |
| Chat        | Yes                                    |

<Note>
  The catalog ID and the display name differ: the entry deploys as `github-file-finder` and presents
  itself as GitHub Agent once it reports in. Use the ID when calling the deploy API.
</Note>

## In a workflow

It sits downstream of an investigation, not in place of one. A workflow that has localised a failure
to a service passes the findings here to turn "this is broken" into "this file is why" — and its
shortlist is what a remediation step then acts on.

See [Orchestration](/manage-your-agents/run/orchestration) for how a step delivers work to it.

## What it will not do

It never modifies a repository. No branch, no commit, no pull request — it reads and recommends.
Opening the pull request that applies a fix is [Remediation
Executor](/manage-your-agents/build/catalog/remediation-executor)'s job.

It also does not tell you what to do right now. Its recommendation is the durable code change that
stops a problem recurring, which is a different question from how to restore service during an
incident.

## Next steps

<CardGroup cols={2}>
  <Card title="Code Reviewer" href="/manage-your-agents/build/catalog/code-reviewer">
    The same repositories, read to review a change before it merges.
  </Card>

  <Card title="Remediation Executor" href="/manage-your-agents/build/catalog/remediation-executor">
    Turn the recommended change into a pull request.
  </Card>

  <Card title="Built-in integrations" href="/manage-your-agents/build/built-in-integrations">
    Create the GitHub connection this agent needs.
  </Card>

  <Card title="Agent catalog" href="/manage-your-agents/build/catalog/overview">
    Every catalog agent, side by side.
  </Card>
</CardGroup>


## Related topics

- [Code Reviewer](/manage-your-agents/build/catalog/code-reviewer.md)
- [Agent catalog](/manage-your-agents/build/catalog/overview.md)
- [Built-in integrations](/manage-your-agents/build/built-in-integrations.md)
- [Remediation Executor](/manage-your-agents/build/catalog/remediation-executor.md)
- [Concepts & glossary](/get-started/concepts.md)