Building a Self-Hosted Multi-AI Gateway

allowUnsafeSshCommand blocked by default

simple-git 3.x blocks the GIT_SSH_COMMAND environment variable unless you explicitly opt in with unsafe: { allowUnsafeSshCommand: true } in the constructor options. Setting the environment variable through runtime config doesn't bypass this — the check happens at the options level before any env is read. Every git operation failed with "core.sshCommand is not permitted without enabling allowUnsafeSshCommand" until the option was passed to both the working git instance and the separate instance used for cloning.

Parser extracting stop words as repo names

The initial git op parser matched any word that followed a git verb — so "did you pull the chess thing" extracted "the" as the repo name and tried to find a repo called "the". Fixed by validating matched repo names against the configured REPOS env var. Only names that match a known repo key are treated as git targets; everything else is left in the user message.

Silent hang on repo-related context

Gemini CLI has an agentic mode that activates when it detects certain context — repo names, file paths, directory references. In agentic mode it calls shell tools (run_shell_command, list_directory) to gather context before responding. Those tool calls fail silently in the subprocess environment, producing no stdout and no exit. The process just hangs until the 5-minute timeout kills it.

Two fixes were required together. First, --yolo auto-approves all tool calls so nothing blocks on confirmation. Second, the prompt is passed as a direct -p argument instead of stdin — passing via stdin triggers the agentic path; the direct arg approach bypasses it. Both were required; either alone didn't fully solve it.

GEMINI_CLI_TRUST_WORKSPACE not reaching the subprocess

Gemini requires GEMINI_CLI_TRUST_WORKSPACE=true to operate in directories it hasn't approved. This runtime variable was loaded from local configuration — but the subprocess spawned by child_process.spawn uses its own environment constructed in SPAWN_ENV(). The fix was to hardcode it directly in that function so it's always present regardless of what the parent process loaded.

Clone race condition causing "not a git repository"

A single message that triggers both a git pull and an auto-log-fetch on an uncached repo causes two concurrent ensureCloned calls. The first checks for .git, doesn't find it, and starts cloning. The second also checks, doesn't find it yet, removes the partially-created directory, and starts a second clone — leaving the first clone in a broken state. Both then fail with "not a git repository."

Fixed with a per-repo in-memory promise lock (cloneLocks[name]). The first caller stores its clone promise in the lock. The second caller finds the lock, awaits the existing promise, then returns — so the clone only ever happens once, and subsequent callers just wait for it.

AI asked about git with no actual git data

After a pull, if the user asked "what was the last commit?", the AI had no commit data — it was just told the pull result string. Gemini would respond by trying to run git itself inside the subprocess, which fails. Claude would hallucinate or say it didn't have the information.

Fixed by auto-fetching a git log after every git op and injecting it into the prompt as a "Git context" block before the user's question reaches the AI. Now the AI has the actual commit history and can answer from it without needing to run git.

Git phrases sent to Gemini causing re-run

When the full user message (e.g. "pull chess and tell me the last commit") was passed to Gemini, Gemini interpreted "pull chess" as a git instruction and tried to run it inside the subprocess. The fix introduces an aiPrompt field — the original user text with git operation phrases stripped out. The AI receives only the question part; the git ops are handled by the gateway before the AI is called.