gateship

Gateship est un runtime local-first pour agents de codage. L'opérateur définit une tâche, Gateship lui fournit un worktree Git isolé, exécute Claude Code ou Codex local, vérifie les commandes d'acceptance, fait inspecter par un reviewer indépendant en lecture seule et livre via une pull request squash-mergée. L'interface est web-first et local-first : Bun sert l'interface sur 127.0.0.1, SQLite stocke l'état des exécutions, et aucune frappe terminal ni session tmux n'intervient dans le chemin d'exécution. Configuration et gestion des identifiants. Docker Desktop sur Windows et macOS, ou Docker Engine avec le plugin Compose sur Linux, est recommandé pour la portabilité ; l'image inclut les CLIs provider et GitHub. Les installations natives macOS/Linux nécessitent Claude Code et/ou Codex CLI avec abonnement, plus gh authentifié via gh auth login --web et gh auth setup-git. Bun 1.2.3 minimum requis seulement depuis les sources ; Git doit pouvoir créer branches et worktrees. Gateship exécute le binaire claude ou codex de l'utilisateur, transmet un allowlist d'environnement aux enfants agent, ne lit jamais les fichiers credentials provider et n'utilise pas d'Agent SDK ; le shipping GitHub utilise le store de credentials de gh plutôt qu'un token personnel ambiant. Installation et mise à jour. Le script place gateship et l'alias gship dans ~/.local/bin par défaut ; GATESHIP_INSTALL_DIR peut override la destination. Relancer le script remplace l'installation existante, et GATESHIP_VERSION peut pincher une release spécifique. Les builds depuis les sources utilisent bun install --frozen-lockfile puis bun run build:release, ou bun run direct pour développement. Les installations natives peuvent opt-in aux checks de mise à jour (désactivé par défaut) ; le processus vérifie les releases officielles au plus une fois par jour, vérifie le commit tag, l'asset plateforme, SHA256SUMS.txt et la version output, et ne promeut que si aucune exécution non-terminal ni diagnostic actif n'existe. Une release candidate ne retournant pas la version exacte stoppe la mise à jour et restaure le binaire précédent. Démarrage rapide. Exécuter gship depuis un clone GitHub démarre la surface de contrôle locale et affiche http://127.0.0.1:7777, ou gship --port 8080 pour un autre port. À premier chargement, l'interface vérifie uniquement les métadonnées Git locales, l'URL origin et la ref origin/main, sans jamais fetcher ou créer implicitement un repository. Si le dossier est vide ou incomplet, les surfaces opérationnelles affichent la commande de récupération exacte tandis que les paramètres restent accessibles. Le nom opérateur et le fuseau horaire IANA sont optionnels et stockés uniquement après save explicite. Un processus ne peut pas changer son répertoire de travail ; un changement de path projet nécessite de redémarrer Gateship depuis le clone ciblé. Agent CLI. Les agents shell-capable peuvent utiliser le service via une interface versionnée et machine-readable : gship agent guide, gship agent operations, gship agent call status.get, et des appels comme issues.get avec input JSON. Chaque commande agent émet un seul objet JSON sans sortie ANSI ni progression, et un flag URL pointe vers un service sur un autre port. Le workflow navigateur permet de décrire et affiner un travail avec un agent externe invoquant des commandes Gateship typées, maintenir un brief projet durable comme handoff entre sessions, puis autoriser explicitement la tâche. Les décisions interrompent le travail et attendent l'attention ; progression, texte public agent, noms outils, vérification et review sont suivis via SSE ; les notifications navigateur locales peuvent atteindre l'opérateur hors de l'onglet. Claude et Codex peuvent être switchés sans perdre l'état durable de run, et les contrôles explicites servent de fallback déterministe. Un diagnostic React advisory optionnel s'exécute sur un checkout exact-SHA isolé, manuellement ou selon schedule quotidien/hebdomadaire pendant l'inactivité projet ; une finding peut être dismissed ou promue en tâche non approuvée. Les diagnostics restent hors de la delivery gate, ne auto-fixent jamais ni n'approuvent le travail, et aucun score diagnostic ne peut bloquer le shipping. Un panel benchmark rend visibles outcomes, attention humaine, rounds correction, holds provider, wall time, coût et faits provider/model comme items séparés, sans evaluator model ni score synthétique. Runtime flow. Une tâche opérateur part vers un agent conversationnel externe, puis une commande Gateship typée, puis un backlog record sur remote main. Gateship crée un worktree isolé, exécute la session implémentation sélectionnée, vérifie les commandes acceptance, effectue un review indépendant lecture seule via le même provider, tente un fix automatique lors de findings, commit et push, ouvre une PR, squash auto-merge après CI, refresh origin/main, et libère le worktree managed clean et la branche locale. Une issue sans commandes verify échoue au preflight ; le review s'exécute comme session fraîche avec capacités mécaniquement read-only. Distribution conteneur. L'image multi-architecture passe par Docker Desktop sur Windows/macOS et Docker Engine sur Linux, avec variants linux/amd64 et linux/arm64 sous même tag release, contenant le binary compilé, git, GitHub CLI, Claude Code CLI et Codex CLI. Les deux releases provider CLI sont pinned, et les auto-updates Claude Code sont désactivés dans les sessions enfant pour éviter qu'un run ne remplace silencieusement l'exécutable derrière sa revision workflow enregistrée. Compose publish le port sur loopback uniquement, garde le filesystem image read-only, fournit un /tmp éphémère, prévient privilege escalation et droppe les capabilities Linux sauf celles nécessaires pour bind mounts avec uid hôte différent. Provider et GitHub authentication se font dans le conteneur au premier boot et persistent sur un named state volume ; la runtime database SQLite et worktrees du repository sélectionné restent dans le répertoire .gship du projet sur le bind. Recréer le conteneur depuis même image et volume retourne le même état SQLite, worktrees et logins. Le README recommande pour update/recovery un tag image versionné avec manifest digest, stopper le service, backup du state volume et répertoire .gship, et restaurer le digest précédent pour rollback ; gship doctor --json rapporte architecture, image, permissions volume, Git, gh, Claude, Codex, logins et connectivité locale comme états sans credentials. Sécurité. Le serveur HTTP bind uniquement sur 127.0.0.1 par défaut, et mutations navigateur requièrent une requête same-origin localhost ; les routes read n'ont aucune authentification propre, donc le loopback bind est leur seule boundary. L'image conteneur nécessite une variable bind-host à 0.0.0.0 pour le proxy Docker published-port, déplaçant cette boundary vers la façon dont le port est publié sur l'hôte ; publier sur une autre interface exposerait toutes les routes read sans authentification. L'implementer est intentionnellement write-capable dans le worktree isolé et, en mode native, détient l'autorité filesystem de l'utilisateur exécutant Gateship ; le mode conteneur le borne au conteneur et ses mounts explicites. Le resolver et reviewer read-only restreignent Claude à Read/Grep/Glob avec MCP et slash commands disabled, et exécutent Codex dans son sandbox read-only avec user config et MCP disabled. Les enfants agent et GitHub CLI reçoivent un environnement allowlist, tandis que les verification commands sont des projets trusted et conservent l'environnement service. Gateship n'a aucun champ web ou SQLite pour credentials provider ou GitHub ; il s'agit de process containment pour un opérateur unique de confiance, pas d'un multi-tenant secret sandbox. État durable et récupération. Metadata run, sélection provider, events, brief projet maintenu opérateur et un cycle-resolver session id par provider vivent dans un fichier SQLite sous .gship ; chaque run stocke son propre provider, session id natif et worktree path. Au restart service, un in-flight run non-owned devient interrupted et peut être resumed au lieu de perdre le workspace ou démarrer silencieusement un duplicate. Après merge confirmé, Gateship supprime le worktree managed clean, sa branche locale et son stale remote-tracking ref ; un run failed libère de même, sauf qu'une branche portant un commit manquant d'origin/main est préservée, avec worktrees dirty et leftovers non-owned. Le cleanup est retryé au startup. La source runtime est la ref remote origin/main, fetched avant d'admettre un run et après un merge, et la branche main locale utilisateur est intentionnellement laissée intacte. Développement, communauté et license. Le projet build avec Bun et fournit commandes pour type checking, tests, linting et dead-code analysis, avec un ship gate exécutant l'ensemble complet avant release. Les contributions suivent le contributing guide, code of conduct et security policy ; les beta users externes peuvent soumettre observations sanitized via un feedback path documenté que les maintainers triagent manuellement. Gateship est released under MIT license.