Documentation

What is Git Container Console?

GCC is a cloud platform that gives AI coding agents a full, isolated development environment with your Git repository cloned inside. The agent can read files, edit code, run shell commands, execute tests, commit changes, and create merge requests — all from a chat interface.

Each session runs in its own Docker container that persists in the cloud. Close your browser, shut your laptop — the workspace keeps running. Resume sessions later with all state (file changes, git diff, agent context) restored automatically.

Five steps to your first session

Four agents, one platform

Each harness runs natively in the container with its own CLI binary, session persistence format, and configuration structure. You choose which agent to use when creating a session.

Claude Code

Anthropic's official CLI agent. Supports skills, agents, hooks, and scripts. Models: Opus 4.6, Opus 4.6 (1M context), Sonnet 4.6, Sonnet 4.6 (1M context), Haiku 4.5. Thinking levels: High, Medium, Low.

OpenAI Codex

OpenAI's code agent. Supports skills, subagents, and hooks. Models: GPT-5.4, GPT-5.4 Mini, GPT-5.3 Codex. Some models require a ChatGPT Pro subscription (OAuth).

Pi.dev Agent

Multi-provider agent supporting both Anthropic and OpenAI models. Supports skills, extensions, and prompt templates. Unique feature: models from different providers (e.g., Claude Sonnet via Anthropic key, GPT-5.4 via ChatGPT subscription) on the same agent.

OpenCode

Provider-agnostic agent. Supports skills, agents, and plugins. Models: Claude Sonnet 4.6, Claude Opus 4.6, GPT-5.4.

Container lifecycle

Understanding how containers are created, managed, and cleaned up:

Creation

When you start a session, a Docker container is created with your repo cloned, git credentials configured, and the AI agent installed. Ready in seconds.

Running

While running, you can chat with the agent, upload files, and see real-time file changes. Multiple users can view the same session simultaneously.

Idle & State Capture

After approximately 30 minutes of inactivity, the container's workspace state is captured: file changes, untracked files, and agent conversation history. The container is then stopped to free up resources.

Resume

When you return to a stopped session and send a message (or click "Start Container"), a fresh container boots and restores your saved state — file changes, untracked files, and the agent's conversation history. It appears as if the container was never stopped.

Queue

If all capacity is currently in use, new sessions enter a queue. Queue position is displayed in real-time. When capacity frees up, the next queued session starts automatically.

GitHub, GitLab, and Bitbucket

Each git provider integration stores its own access token, git identity (name/email), and optional system prompt. You can have multiple integrations simultaneously (e.g., one GitLab for work, one GitHub for personal projects).

Supported features per provider

On-demand runtimes & databases

Integrations are installed inside containers when the agent needs them. Each integration is automatically configured inside the container, with an optional skill document that teaches the agent how to use it.

Available integrations: PostgreSQL 17, MariaDB (MySQL-compatible), Playwright (Chromium headless), Node.js (18/20), Python (3.11/3.13), Go (1.22-1.24), Rust, Java (OpenJDK 17/21 + Maven), PHP (8.2-8.4 + Composer), .NET (8.0-10.0), and Ruby (rbenv 3.2-3.4 + Bundler).

Integrations are enabled per-repository from the Store page or repository settings. Configuration (e.g., database name, runtime version) is customizable per-repo.

Skills, agents, hooks, and more

Each harness supports different configuration types that are injected into the container on session start:

• Skills — Markdown documents that teach the agent domain-specific knowledge (all harnesses)
• Subagents / agents — Task-specialized agent definitions (Claude Code, Codex, OpenCode)
• Hooks — Lifecycle hooks triggered by the agent (Claude Code, Codex)
• Scripts — Executable files used by Claude Code hooks
• Extensions — TypeScript extensions for tool augmentation (Pi.dev)
• Prompt templates — Reusable slash-command prompts (Pi.dev)
• Plugins — TypeScript plugins (OpenCode)

Configs can be marked as "enabled by default" (applied to all sessions) or enabled per-repository in repository settings. Project-level instructions belong in the repository's own AGENTS.md / CLAUDE.md, not in harness config settings.

Cron jobs

Cron jobs run prompts on a schedule (minimum interval: 1 hour). Each execution creates a new chat session with the configured prompt, repository, branch, harness, model, and effort level.

Key behaviors:

• If a previous session from the same cron job is still running, the next execution is skipped
• Cron jobs can be manually triggered from the UI for testing
• Session history shows all executions with their container status
• Disabling a cron job clears its next scheduled run
• Push notifications are sent when cron-triggered sessions complete

REST API & Webhooks

The external API at /api/v1/ provides programmatic access to core features. All requests require a Bearer token with a gcc_-prefixed API key.

API Endpoints

• GET /api/v1/repositories/ — List your repositories
• POST /api/v1/sessions/ — Create a session with repository, branch, prompt, harness, model, effort
• GET /api/v1/sessions/{id}/ — Get session details and container status
• GET /api/v1/sessions/{id}/messages/ — Fetch conversation history
• POST /api/v1/sessions/{id}/cancel/ — Cancel a running session
• GET /api/v1/harnesses/ — List available harnesses with models and thinking levels
• GET /api/v1/status/ — Check available capacity and queue depth

API reference: app.git-container-console.com/api/v1/docs/

Webhooks

Configure webhook endpoints to receive POST requests when sessions complete or error. Payloads include session metadata, token usage, and timing. If a signing secret is configured, payloads are signed with HMAC-SHA256 (header: X-Webhook-Signature). Failed deliveries are retried automatically. Webhook endpoints must use HTTPS.

Security model

Credential encryption

All sensitive credentials (API keys, git tokens, OAuth tokens, webhook secrets, environment variables) are encrypted at rest. Credentials are decrypted only when injected into containers at session start.

Container sandboxing

Each container runs in a sandboxed Docker environment with restricted capabilities and a dedicated network. Containers can only access the public internet (HTTP/HTTPS and DNS) — they cannot reach internal services or other containers.

Authentication

The web UI uses session-based authentication with CSRF protection. The REST API uses Bearer token authentication with API keys. Optional two-factor authentication (TOTP) with recovery codes is available.

Data handling & retention

What we store

• Account data (email, username, hashed password, 2FA secret)
• Git provider metadata (repo names, branches — not code)
• Chat messages and tool call history
• Workspace state snapshots (encrypted) for session resume
• Token usage statistics per message

What we don't store

• Your code outside of active/suspended containers (repos are cloned on demand)
• Plaintext credentials (everything is encrypted at rest)
• AI model training data (your code and conversations are never used for training)

Data location

All infrastructure runs on European servers (EU-based).

Usage & cost tracking

The built-in usage dashboard shows per-session token breakdowns (input, output, cache read, cache write), cost estimates, daily/weekly/monthly trends, day-of-week patterns, repository-level breakdowns, and 30-day cost projections. Filter by time period, harness, and model.

Cost estimates are calculated from model pricing for Codex models. For Claude models, costs are reported by the API when available. Duration tracking shows how long each agent turn takes.

Ready to get started?

Create a free account and connect your first repository.