At a glance
An MIT-licensed coding harness whose Go runtime implements an adaptive model-and-tool loop, repository and shell mutation, automatic context compaction, project memory, resumable JSONL sessions, provider switching, subagents, persistent teammates, independent worktree workers, policy modes, hooks, traces, checkpoints, MCP, and browser automation.
Good choice if
- Terminal workflows that need several providers, local OpenAI-compatible endpoints, MCP, and built-in browser control
- Long autonomous tasks that benefit from resumable context, parallel agents, scheduled execution, and local execution traces
- Governed change delivery through isolated Git worktrees, configured checks, review, approval, promotion, and release stages
Check before choosing
- Normal execution is host-first: path policy, protected-file rules, and Git worktrees constrain access and change organization but are not an OS or container security boundary
- The sandboxed JavaScript VM is limited to programmatic calls to read-only tools; it does not isolate file writes, shell commands, MCP servers, plugins, hooks, browser actions, or external side effects
- Bypass and autopilot modes deliberately weaken interactive approval, while harness workers launch independent GGCode processes in bypass mode inside an allowed worktree path
See 4 more considerations
- Subagents and swarm teammates share the main process and workspace; only harness workers receive a separate process and worktree, and even that process is not an OS sandbox
- File checkpoints cover edits made through GGCode tools and cannot reverse shell commands, Git operations, browser actions, messages, or external-service effects
- Hooks and plugins execute trusted user-supplied code, MCP servers retain their own trust boundary, and the broad desktop, web, mobile, messaging, and automation surface increases configuration responsibility
- Exported session traces and harness event logs improve local inspection, but they do not establish task success or independent product performance