# Hydrant and GitHub Issues

Comparisons · September 26, 2026 · Henry Kobutra with Codex

![Fine code-like rows on the left converge into a single orange connection to a structured issue card on the right.](/log/images/hydrant-and-github-issues/cover.webp)

*Choosing your tracker*

**Last reviewed: 2026-09-25**

Choose GitHub Issues when the repository is the natural boundary of the work and the shortest path from task to pull request matters most. Choose Hydrant when the issue must describe a delivery process that extends beyond the repository and includes named agents, refinement, dependencies, release evidence and human acceptance.

GitHub's advantage is proximity. The code, issue, branch, pull request, review and checks already live in one service.

## GitHub keeps planning beside the code

[GitHub Issues](https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues) supports assignees, labels, milestones, sub-issues, dependencies and links to pull requests. A merged pull request can close its issue with a keyword. GitHub Projects adds [tables, boards, roadmaps, custom fields, charts and automation](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), and a project can draw work from multiple repositories.

That is a strong fit for an open-source project or a product team whose delivery record is mostly commits and pull requests. Contributors need one account and can move from a line of code to the issue that explains it without changing systems.

GitHub also supports agent work directly. Its official [MCP server](https://docs.github.com/en/copilot/how-tos/provide-context/use-mcp-in-your-ide/use-the-github-mcp-server) can work with repositories, issues and pull requests. Copilot's cloud agent can take an issue and open a pull request, and GitHub documents [third-party coding agents](https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents) doing the same in public preview. Plans and policies control some of those features.

## Hydrant makes the ticket the handoff

Hydrant is a separate workspace. It does not host Git repositories, pull requests or CI. That extra boundary is a cost when GitHub already contains the whole job.

The boundary helps when the job spans more than code. Hydrant records whether a request is refined, which unfinished issues block it, who or which named agent owns it, what evidence was produced, and whether a person accepted the result. Its [agent connections](/help/agents/connect) are workspace-scoped, and versioned writes refuse to flatten a newer edit.

Some of that discipline can be built in GitHub with issue fields, Projects, Actions and team conventions. Hydrant packages a particular small-team loop around it. Its optional workflow pack remains guidance for the connected agent, and review stages remain statuses rather than enforced approvals.

Use GitHub Issues when code is the centre and its flexible primitives are enough. Use Hydrant when the ticket needs to remain the centre even while repositories, agents and release steps change around it.

Contact: bots@hydrant.dev