# GitBot

GitBot is a local, open-source orchestration hub that turns Claude Code, Codex, or OpenCode into reusable bots with persistent threads and per-bot permissions. It adds a browser workspace and repeatable agent roles without replacing the coding agents you already use.

Canonical URL: https://aiidelist.com/ide/gitbot

Language: en

Updated: 2026-10-05

## Overview

- Category: Developer Workflow Tools
- GitBot is a local-first orchestration layer for turning existing coding-agent CLIs into reusable, permissioned bots that can be run across repositories from a browser workspace.
- Editor base: Standalone
- Platforms: macOS, Linux, Windows
- Open source: Yes
- Local model support: Yes
- Bring your own API key: Yes

## Quick verdict

GitBot is most compelling for developers who already have a preferred coding agent and want to turn repeated instructions into reusable, locally run roles. It is less suitable as a shared team service until its network authentication and administration story matures.

## Best for

- Developers who already use Claude Code, Codex, or OpenCode and want reusable agent roles
- Recurring repository workflows such as code review, documentation checks, testing, maintenance, and release preparation
- Local-first users who want persistent agent threads without moving repositories into a hosted IDE
- Teams or individuals experimenting with portable bot instructions and permission boundaries

## Strengths

- Works with existing Claude Code, Codex, and OpenCode logins
- Reusable bot definitions reduce repeated prompt setup across repositories
- Local storage avoids a GitBot-hosted conversation database
- Agent choice can be changed per bot instead of locking the workflow to one vendor

## Limitations

- Users looking for a full AI-native code editor
- Teams that need a hosted multi-user service with SSO, authentication, or centralized administration
- Users who want a coding model included without installing or authenticating a separate agent
- Environments where the GitBot port would need to be exposed directly to an untrusted network
- The local server has no authentication and should not be exposed to the public internet
- Codex does not support GitBot's per-tool approval flow or tool allow/deny fences
- It is an orchestration layer, so an underlying coding agent must already be installed and authenticated
- The project is still in an early 0.x release line, so behavior and interfaces may change quickly

## Why Choose GitBot?

GitBot addresses a different problem from an AI code editor or a standalone coding agent. The underlying intelligence still comes from Claude Code, Codex, or OpenCode; GitBot adds a durable operating layer above them.

That matters when the same instructions are being repeated across repositories. A developer may regularly ask an agent to review a branch, audit documentation, find test gaps, prepare release notes, or explain an unfamiliar codebase. In a normal CLI session, much of the role definition has to be restated or reconstructed. GitBot turns that recurring job into a named bot with standing instructions and an explicit permission model.

The practical advantage is consistency. The repository changes from thread to thread, while the role can remain stable. This makes GitBot closer to a reusable agent workflow system than to another chat interface.

## Core Workflow

GitBot runs a local server between the browser and coding-agent CLIs already installed on the machine. A bot defines the recurring job, the agent that should execute it, its permission mode, and optional one-time setup instructions. A thread then combines that bot with a specific folder and conversation history.

The separation between bot and thread is important. The bot is the reusable policy; the thread is the working session. This lets the same review bot operate in several repositories without copying a long system prompt into every new conversation.

A typical local launch is:

```bash
npm install -g @gitbot-hq/gitbot
cd /path/to/your/projects
gitbot start
```

The browser UI then becomes the control surface, while the selected agent continues to execute on the local machine. GitBot therefore does not require migrating a repository into a cloud IDE or learning a replacement editor.

## Use Cases

GitBot fits recurring jobs better than one-off prompts. Strong examples include repository reviewers, codebase guides, documentation auditors, test-gap finders, maintenance bots, and release-preparation assistants.

It is also useful when a developer wants to compare agent backends without redesigning the workflow around each one. A reusable job can be defined once, then assigned to an available agent. This does not make different agents behaviorally identical, because their permission and sandbox models differ, but it reduces the surrounding workflow changes.

The public GitBot Library pushes this concept further. Bot definitions can be inspected before installation, and shared definitions do not include the original chat history or local project files. That makes the reusable unit closer to a portable agent role than a shared conversation transcript.

## Comparison to Alternatives

Claude Squad is the closer choice for developers whose main problem is running several coding-agent tasks in parallel. Its workflow is terminal-first and emphasizes isolated workspaces and reviewing changes before applying them. GitBot is more role-centric: it packages a recurring job as a bot and gives that bot persistent browser-based threads.

Agent Deck is also aimed at developers managing many local agent sessions, but its center of gravity is an operator console for sessions, worktrees, status, and fleet management. GitBot is easier to understand as a library of repeatable jobs that happen to run on different agent backends.

cmux-style agent managers focus more heavily on parallel execution, isolated workspaces, and task supervision. GitBot is a better conceptual fit when the reusable instruction set itself is the asset: for example, a standard reviewer, test writer, or release assistant that should behave consistently across repositories.

Because of this distinction, Cursor, Windsurf, and other AI-native editors are not direct replacements. They compete for the editing environment, while GitBot is designed to sit above agent CLIs that can coexist with an existing editor.

## Best Configuration

The most important configuration decision is not the model; it is the permission boundary. For unfamiliar bots or repositories, start with the most restrictive mode that still lets the job succeed. Read-only analysis is appropriate for reviewers and codebase explainers. Workflows that need edits should normally begin with approvals enabled rather than broad automatic execution.

Agent selection also changes the safety model. Claude Code and OpenCode can surface tool approval requests through GitBot and can use allow or deny tool lists. Codex is integrated differently: GitBot relies on its sandbox mode instead of per-action approvals, and GitBot cannot enforce the same tool list restrictions for Codex.

Network exposure deserves equal attention. The browser UI is convenient on another device on the same trusted network, but the server currently has no authentication. Treat the GitBot port like a local developer service with access to powerful agents: do not publish it through a public reverse proxy or expose it directly to the internet.

For local-model or bring-your-own-provider workflows, GitBot does not provide its own inference engine or credential store. Those capabilities are indirect through the selected coding agent, particularly OpenCode when it is configured with a custom or local provider. Model connectivity, credentials, and model compatibility therefore remain responsibilities of the underlying agent layer.

## Migration Notes

Moving from direct Claude Code, Codex, or OpenCode usage is lightweight because GitBot does not replace those tools. Existing agent installation and authentication remain the foundation; GitBot adds reusable definitions and persistent thread records around them.

The main migration task is deciding which prompts deserve to become durable bots. A useful rule is to convert only work that has a stable role, repeatable constraints, and a recognizable definition of done. One-off debugging requests are usually better left as ordinary agent sessions.

Bot sharing is also different from exporting an entire workspace. Shared bot definitions carry the reusable instructions and settings, not local files or chat history. That makes them suitable for standardizing a workflow without automatically distributing repository context.

There is little repository lock-in: the code remains in normal local folders and the underlying agents remain independently usable. The GitBot-specific state to account for is its local bot and thread data, stored under `~/.gitbot` by default. If GitBot is removed, repositories do not need to be converted back to another format; only GitBot's saved workflow layer is lost unless those bot definitions have been shared or preserved separately.

## Features

### Agent Orchestration

- Create reusable bots with standing instructions
- Run Claude Code, Codex, or OpenCode per bot
- Keep persistent threads tied to a selected folder

### Control & Permissions

- Choose read-only, approval-based, or broader permission modes
- Review tool approvals in the browser for Claude Code and OpenCode
- Use allow or deny tool lists with supported agents

### Local Workflow

- Run a local browser workspace from your machine
- Store bots and thread records locally by default
- Share bot definitions or install community bots from the Library

## Installation

````````sh
npm install -g @gitbot-hq/gitbot
````````

## Pricing

open-source

- Open Source: $0 — MIT-licensed GitBot software. Any subscription, API, or model usage costs come from the connected coding agent or provider.

Pricing checked: 2026-10-05

## Privacy and data handling

GitBot states that it has no account, telemetry, or hosted database, and stores bot and thread records under ~/.gitbot by default. The selected coding agent may still send prompts and code to its configured model provider. GitBot's local server currently has no authentication and listens on network interfaces, so it should be used only on a trusted network and not exposed publicly.

## Alternatives

- Claude Squad
- Agent Deck
- cmux

## Sources

- [Official website](https://github.com/gitbot-hq/GitBot)
- [Documentation](https://github.com/gitbot-hq/GitBot#readme)
- [Installation](https://www.npmjs.com/package/@gitbot-hq/gitbot)
- [Download](https://github.com/gitbot-hq/GitBot)
- [GitBot GitHub Repository](https://github.com/gitbot-hq/GitBot)
- [GitBot npm Package](https://www.npmjs.com/package/@gitbot-hq/gitbot)
- [GitBot Library](https://gitbot.codeongrass.com/)
- [GitBot Architecture Notes](https://github.com/gitbot-hq/GitBot/blob/main/docs/ARCHITECTURE.md)

Last checked: 2026-10-05
