gateship

O Gateship é um runtime local-first para agentes de codificação. Um operador define uma tarefa, e o Gateship oferece um worktree Git isolado, executa o cliente local Claude Code ou Codex selecionado, verifica os comandos de aceitação definidos na tarefa, solicita a um revisor independente read-only que inspecione a mudança e entrega o resultado por meio de um pull request squash-merged. O produto é web-first e local-first: o Bun serve a interface em 127.0.0.1, SQLite armazena o estado das execuções e a atividade, sem teclas de terminal ou sessão tmux no caminho de execução. Requisitos e tratamento de credenciais. Docker Desktop no Windows e macOS, ou Docker Engine com o plugin Compose no Linux, é a instalação recomendada quando a portabilidade do host é necessária, e a imagem inclui os CLIs do provedor e do GitHub. Instalações nativas no macOS e Linux precisam do Claude Code e/ou CLI Codex com login por assinatura, além do GitHub CLI autenticado via gh auth login --web e gh auth setup-git. Bun 1.2.3 ou superior é necessário apenas ao executar a partir do código-fonte, e Git deve ser capaz de criar branches e worktrees no repositório de destino. O Gateship executa o binário claude ou codex do operador conectado, passa aos filhos do agente um allowlist de ambiente, nunca lê arquivos de credenciais do provedor e não utiliza Agent SDK; o envio via GitHub usa o credential store pertencente ao gh, não um token pessoal ambientado. Instalação e atualização. O script de instalação posiciona gateship e o alias curto gship em ~/.local/bin por padrão, com GATESHIP_INSTALL_DIR para substituir o destino; reexecutá-lo substitui uma instalação existente no local, e GATESHIP_VERSION pode fixar um release específico. Builds de fonte usam bun install --frozen-lockfile seguido de bun run build:release, e o Bun também pode executar o entry point diretamente para desenvolvimento. Instalações nativas podem optar, off por padrão, por verificações de atualização nas Configurações; o processo em execução verifica releases oficiais no máximo uma vez ao dia, verifica o commit da tag do release, o asset da plataforma atual, SHA256SUMS.txt e a própria saída de versão do candidato, então transfere apenas enquanto não existir nenhuma execução sem terminal ou diagnóstico ativo. Um candidato que não retorne a versão e o commit exatos do release é interrompido, e o binário anterior é restaurado, reiniciado e verificado. Aplicações automáticas estão indisponíveis em containers e checkouts de fonte; eles informam o motivo. Quick start. Executar gship a partir de um clone do GitHub inicia a superfície de controle local e exibe http://127.0.0.1:7777, e gship --port 8080 seleciona outra porta. Na primeira carga, a interface web verifica apenas metadados locais do Git, a URL do origin e o ref origin/main local, e nunca busca ou cria um repositório implicitamente. Se o diretório estiver vazio ou incompleto, superfícies operacionais mostram o comando exato de recuperação enquanto configurações permanecem disponíveis para configuração de assinatura do agente. O nome do operador e o timezone IANA são opcionais e armazenados apenas após um save explícito. Um processo em execução não pode trocar seu working directory, então um projeto alterado exige reiniciar o Gateship a partir do clone pretendido. Agent CLI. Agentes com capacidade de shell podem usar o serviço em execução por meio de uma interface versionada e legível por máquina em vez de iniciar outro runtime ou editar o diretório .gship diretamente: gship agent guide, gship agent operations, gship agent call status.get e chamadas como issues.get com input JSON. Cada comando do agente emite um único objeto JSON sem output ANSI ou de progresso, e uma flag URL aponta para um serviço em execução em outra porta. O fluxo de trabalho no navegador permite que um operador descreva e refine o trabalho com um agente externo que invoca comandos typed do Gateship, mantenha um brief projetual durável como handoff entre sessões e autorize a tarefa explicitamente. Decisões interrompem o trabalho e aguardam atenção, enquanto progresso, texto público do agente, nomes de ferramentas, verificação e revisão são acompanhados via SSE; notificações do navegador local podem alcançar o operador fora da aba. Claude e Codex podem ser alternados sem perder o estado de execução durável, e controles explícitos atuam como fallback determinístico. Um React diagnóstico advisory opcional é executado contra um checkout exact-SHA isolado, manualmente ou em agendamento diário ou semanal enquanto o projeto está inativo; uma finding pode ser descartada ou promovida a uma tarefa não aprovada. Diagnósticos permanecem fora do delivery gate, nunca corrigem automaticamente ou aprovam trabalho, e nenhuma pontuação de diagnóstico pode bloquear o shipping. Um painel de benchmark mantém resultados, atenção humana, rodadas de correção, holds do provedor, tempo de parede e fatos do provedor ou modelo visíveis como itens separados, sem evaluador de modelo ou pontuação sintética. Fluxo de runtime. Uma tarefa do operador é encaminhada a um agente conversacional externo, depois a um comando typed do Gateship e a um registro no backlog no main remoto. O Gateship cria um worktree isolado, executa a sessão de implementação selecionada, verifica os comandos de aceitação, realiza uma revisão independente read-only pelo mesmo provedor, tentativas de one automatic fix quando findings existem, commits e pushes, abre um pull request, squash auto-merge após CI, refresca o origin/main e libera o worktree gerenciado limpo e a branch local. Uma issue sem comandos verify falha no preflight, e a revisão é executada como uma sessão fresca com capacidades mecanicamente read-only. Distribuição por container. A imagem multi-architecture roda via Docker Desktop no Windows e macOS e Docker Engine no Linux, com variants linux/amd64 e linux/arm64 sob o mesmo release tag, e contém o binary compilado, git, o GitHub CLI, o Claude Code CLI e o Codex CLI. Ambas as versões dos CLIs dos provedores estão pinadas, e auto-updates do Claude Code estão desabilitados nas sessões filhas para que uma execução não substitua silenciosamente o executable por trás de sua revision de workflow gravada. Compose publica a porta apenas para loopback, mantém o image filesystem read-only, fornece /tmp efêmero, previne privilege escalation e drop de capabilities do Linux exceto aquelas necessárias para bind mounts com uid do host diferente. Autenticação do provedor e do GitHub ocorre dentro do container no primeiro boot e persiste em um volume named de state; o banco de dados de runtime do repositório selecionado e os worktrees permanecem no diretório .gship do projeto no bind. Recriar o container a partir da mesma image e volume retorna o mesmo estado SQLite, worktrees e logins. Orientações de update e recovery no README solicitam uma versioned image tag com manifest digest, parar o serviço, fazer backup do volume de state e do diretório .gship, e restaurar o digest anterior para rollback; gship doctor --json relata arquitetura, image, permissões de volume, Git, gh, Claude, Codex, logins e conectividade local como states sem credenciais. Segurança. O HTTP server bind apenas a 127.0.0.1 por padrão e mutações do browser adicionalmente exigem um localhost request same-origin; rotas de leitura não possuem authentication própria, então o loopback bind é sua única boundary. A container image precisa de uma bind-host variable definida como 0.0.0.0 para o published-port proxy do Docker alcançar o serviço, o que move essa boundary para como a porta é publicada no host; publicar em outra interface expondria todas as read routes não autenticadas. O implementer é intencionalmente write-capable dentro do worktree isolado e, em modo native, detém a autoridade do filesystem do usuário que executa o Gateship; o modo container limita isso ao container e seus mounts explícitos. O read-only resolver e reviewer restringem Claude a Read, Grep e Glob com MCP e slash commands desabilitados, e executam Codex em seu read-only sandbox com configuração de usuário e MCP desabilitados. Filhos dos CLIs do agente e do GitHub recebem um environment allowlist, enquanto os comandos de verificação são comandos confiáveis do projeto e mantêm o environment do serviço. O Gateship não possui campos web ou SQLite para credenciais do provedor ou do GitHub; isto é containment de processo para um único operador confiável, não um multi-tenant secret sandbox. Estado durável e recuperação. Metadados de execução, seleção do provedor, eventos, o brief projetual mantido pelo operador e um cycle-resolver session id por provedor vivem em um arquivo SQLite sob .gship; cada execução armazena seu próprio provedor, session id native e caminho do worktree. Quando o serviço reinicia, uma execução in-flight unowned se torna interrupted e pode ser resumida em vez de perder o workspace ou silenciosamente iniciar um duplicate. Após um merge confirmado, o Gateship remove o worktree gerenciado limpo, sua branch local e seu remote-tracking ref stale; uma execução com falha é liberada da mesma forma, exceto que uma branch contendo um commit ausente do origin/main é preservada, junto com worktrees dirty e leftovers unowned. Limpeza é retryada na inicialização. A source de runtime é o ref origin/main remoto, fetchado antes de admitir uma execução e após um merge, e a branch main local do usuário é intencionalmente deixada intocada. Desenvolvimento, comunidade e license. O projeto constrói com Bun e fornece commands para type checking, testes, linting e dead-code analysis, com um ship gate que executa o full set antes do release. Contribuições seguem o contributing guide, code of conduct e security policy, e usuários beta externos podem enviar observações sanitized por meio de um feedback path documentado que maintainers triam manualmente. O Gateship é liberado sob a MIT license.