fix(init): refuse provider logins without a terminal instead of hanging (#711)

[SaulMoro]

Summary

teamai init with no provider session and no terminal sat inside a browser login for about five minutes, then exited with the provider's error and no hint of the missing credential (#711). The non-TTY guard lived only in utils/prompt.ts; a provider login is a child process that owns the terminal, so it never went through that guard.

 init
   provider.authenticate()
-    github   gh auth login --web   stdio inherit   blocks until the device-flow deadline
-    tgit     gf auth login         stdio inherit   blocks
-    cnb      cnb login             stdio inherit   blocks
+    github   not interactive? throw "Export GITHUB_TOKEN (or GH_TOKEN)…"   else gh auth login
+    tgit     not interactive? throw "Run `gf auth login` first…"           else gf auth login
+    cnb      not interactive? throw "Export CNB_TOKEN…"                    else cnb login
     gitcode  already guarded, the pattern copied here
     gitlab   already throws naming GITLAB_TOKEN
   provider.cloneRepo()
-    git clone                      may prompt for a password or open a credential helper dialog
+    git clone                      terminal prompt, askpass and GCM all closed by the CLI
+                                   when not interactive (utils/git-env.ts); ssh keeps
+                                   whatever core.sshCommand each repo configured

 utils/prompt.ts
-  process.stdin.isTTY                 at every prompt
+  isInteractive() = stdin.isTTY && !CI && !TEAMAI_NONINTERACTIVE

One predicate, isInteractive(), now answers "can a person reply?" for every prompt, the five isTTY checks with prompt semantics (init.ts agent picker, update.ts update prompt, gitcode token paste, local-agent.ts project binding, and the three helpers in prompt.ts), the three provider logins, and the git environment. That git environment covers git's own questions only — the terminal prompt, the askpass dialog and the credential manager window. ssh is not covered: its batch flag is only reachable through GIT_SSH_COMMAND, which would override whatever core.sshCommand each repository configured, so an ssh remote can still ask for a key passphrase or an unknown-host confirmation (see Notes for how to close it per repository). Two init prompts that have no default now fail naming what replaces them: --role <id> with the valid ids when the team has several roles, and the repo argument or --repo when none was given. The six isTTY checks that read a hook payload from stdin keep their own meaning and are untouched. No new flag: a CI runner already exports CI, and an agent sandbox that allocates a pseudo-terminal sets TEAMAI_NONINTERACTIVE=1. --force keeps its meaning.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature causing existing behavior to change)
• Documentation only
• Refactor / internal cleanup

Test Plan

• npx tsc --noEmit passes
• CI=true npx vitest run: 3786 tests pass, 1 skipped, no failures, three consecutive runs on the rebased branch (five before it), launched the way CI does (SHELL=/bin/bash). Worth knowing for anyone running it from zsh: detectShellProfile reads SHELL before its platform branch, so three win32 cases in shell-profile.test.ts resolve .zshrc and fail under a zsh login shell. That is a pre-existing dependency in a file this PR does not touch — CI's four matrix legs are green — so it is left for its own PR rather than widened into this one.
• npx vitest run --config vitest.e2e.config.ts: 40 files, 174 tests pass, 26 skipped (live provider tests without credentials). Run on this exact source; the rebase that followed carried only skill documentation.
• Review rounds 1-3 (see the PR comments): git-env.test.ts (5 cases, including the one that pins GIT_SSH_COMMAND as never set) and the corrected TGit guard assertion in gf-cli.test.ts.
• Added tests: prompt-interactive.test.ts (predicate and every prompt under CI=true on a TTY), guard cases in github-provider.test.ts, gf-cli.test.ts, cnb-login-host.test.ts (each asserts the login is never spawned and the message names the variable), and e2e/init-unattended.test.ts (fake gh on PATH whose auth login sleeps). The e2e test needs no network or secrets, so ci.yml runs it in the build job next to the OpenCode recall test, on every PR.

Evidence

Reproduction from the issue: fake gh with no session and a sleeping auth login, isolated HOME, no token, stdin closed.

• Before (origin/main at 2c0ae96, killed after 8 s; the real gh takes about five minutes to reach exit=1):

  ℹ Not logged in — starting authentication
  ℹ Starting GitHub authentication via gh CLI...
  ! First copy your one-time code: XXXX-XXXX
    Open this URL to continue in your web browser: https://github.com/login/device
  <still running after 8s>
  

  After:

  ℹ Not logged in — starting authentication
  ✖ Authentication failed: GitHub authentication unavailable without a terminal. Export GITHUB_TOKEN (or GH_TOKEN) with "repo" scope, or run `gh auth login` in an interactive shell first.
  exit=1 after 0s
  

Real CLI, end to end

Built CLI, isolated HOME with the four agent roots present, CI=true, stdin closed, throwaway private GitHub repo (deleted afterwards). Paths redacted.

1. init, GitHub, no credential            exit=1 in 0s, message names GITHUB_TOKEN
2. init, GITHUB_TOKEN exported,
   --agent claude,codex,codebuddy,opencode exit=0 in 8s, hooks written for all four
3. skills landed                          teamai/ and team-wiki-codebase/ under
                                          .claude, .codex, .codebuddy, .config/opencode
4. pull                                   exit=0, already up to date
5. doctor                                 exit=0, All checks passed
6. re-init without --force                prompt answers itself: "Aborted. Existing config is unchanged." exit=0 in 0s
7. git children (wrapper on PATH logging the variable, ambient value removed first)
     stdin closed                         every git call: GIT_TERMINAL_PROMPT=0
     pseudo-terminal (script) + CI=true   every git call: GIT_TERMINAL_PROMPT=0
     pseudo-terminal, no CI (control)     every git call: GIT_TERMINAL_PROMPT=<unset>
8. uninstall --force                      exit=0
9. init --self (provider git) with the four agents, business repo on GitHub
                                          exit=0, .claude .codex .codebuddy .opencode .teamai created,
                                          "[teamai] Initialize single-repo mode" committed on main

gitlab was exercised against a live instance with GITLAB_TOKEN. Not run: the tgit / cnb logins against their real CLIs — their guards sit in front of the spawn, the TGit path was driven with a fake gf that reproduces the hang, and both are covered by the unit tests above; the message text is the only thing a live run would add.

Related Issues

Closes #711

Notes for Reviewers

Door: two-way. Revert restores the previous behaviour with no data or config migration; the CLI writes nothing new.

Blast radius: prompts.

• CI=true now makes every prompt take its default even on a TTY. GitHub Actions and most CI services export it, so a workflow that today types answers into an interactive teamai init on a pty would start getting defaults instead. That is the intended behaviour and the documented way to run unattended, but it is the one observable change for existing users.
• Each git variable is set only when the CLI's own environment lacks it, so a caller's explicit value wins. All three name a prompt and nothing else, so one value is right for every repository a run touches. GIT_SSH_COMMAND is deliberately not among them: it overrides core.sshCommand for every later git operation, so a process-wide value would push the launch directory's key or wrapper onto the managed team repo, or suppress the one that repo configured (fix(init): refuse provider logins without a terminal instead of hanging (#711) #713 review round 3). An ssh remote that would still ask is closed per repository (git config core.sshCommand 'ssh -o BatchMode=yes') or per run (GIT_SSH_COMMAND); with stdin closed, ssh's own tty read hits EOF and fails in about a second anyway.
• e2e.test.ts keeps its GitHub-only skip for the sandboxed init test. The comment there described a permanent hang, which this PR removes. What remains is that gf auth whoami reads only gf's own credential store, which an isolated HOME loses; the TGIT_TOKEN the test exports reaches neither (the PAT is REST-API-only, and git.woa.com's git endpoint rejects it too). A TGit run would now fail fast rather than hang, but it still cannot pass, so the skip stays with a corrected comment.
• Two judgement calls from the review left as they are: the provider guard blocks each name their own credential (a shared helper would give one wording, but the repo has no shared provider-auth helper and TGit's remedy is not a token at all), and the isInteractive mock is added to the three test files whose code paths reach it rather than to all eleven mocks of prompt.js.
• Docs updated: docs/usage-guide.md and .zh-CN.md (the "fully non-interactive init" paragraph now names the token variable per provider and the two environment variables), skills/teamai/references/setup-admin.md, CHANGELOG.md. README untouched.

[github-actions]

• [P1 blocking] src/providers/tgit/gf-cli.ts:249 — Exporting the suggested TGIT_TOKEN cannot make unattended init succeed. Authentication still relies exclusively on gf auth whoami, and cloning explicitly ignores TGIT_TOKEN because the PAT is REST-only. The command therefore throws the same “Export TGIT_TOKEN” error even when it is already exported. Either implement a complete PAT-based path or instruct users to establish gf/~/.netrc authentication; also correct both usage guides.
• [P1 blocking] src/index.ts:22 — GIT_TERMINAL_PROMPT=0 only disables Git’s own terminal username/password fallback. It does not prevent credential helpers such as Git Credential Manager from opening interactive UI, nor SSH from prompting through /dev/tty. Generic-provider clones can therefore still wait up to their 180-second timeout, contradicting the documented “never waits” guarantee. Suppress those interactive paths too or narrow the guarantee and coverage.

The PR description includes a detailed test plan and real-CLI end-to-end record, so no testing-description issue.

[SaulMoro]

Both P1 findings fixed, plus a regression this PR had introduced that the full suite caught. Rebased on origin/main (9ce8a0e) — one conflict in src/index.ts against the new notifyWebhook block, resolved by keeping both.

P1 — TGIT_TOKEN cannot make an unattended run succeed

Correct, and the message was sending people after a credential that provably cannot work: the PAT is REST-API-only (rest-auth.ts tgitGitCloneUrl rejects it for clone by design), and ensureAuthenticated only ever reads gf auth whoami. So the guard now names the only credential that does work — the one gf auth login stores — and says why the token is not it.

before  Export TGIT_TOKEN (a TGit Personal Access Token), or run `gf auth login` …
after   Run `gf auth login` in an interactive shell first — this machine then reuses
        the credential it stores (TGIT_TOKEN is REST-API-only and cannot clone).

Corrected everywhere the same claim appeared: docs/usage-guide.md, docs/usage-guide.zh-CN.md, skills/teamai/references/setup-admin.md (both the non-interactive paragraph and the "Headless/CI only" aside in Step 3), skills/teamai/references/join-member.md, CHANGELOG.md, and the comment in e2e.test.ts that repeated it. gf-cli.test.ts now asserts the message points at gf auth login, not at a token.

P1 — GIT_TERMINAL_PROMPT=0 leaves three other doors open

Also correct. Rather than narrow the guarantee, all four are closed together in the new src/utils/git-env.ts, each only where the caller set nothing:

variable	door it closes
GIT_TERMINAL_PROMPT=0	git's own username/password question on the terminal
GIT_ASKPASS=echo	the askpass chain (GIT_ASKPASS → core.askPass → SSH_ASKPASS) — on a desktop, a GUI dialog
GIT_SSH_COMMAND='ssh -o BatchMode=yes'	ssh's key passphrase and unknown-host questions, asked through /dev/tty past every git setting
GCM_INTERACTIVE=never	Git Credential Manager's own window, which no git variable reaches

src/index.ts now calls applyNonInteractiveGitEnv() in place of the single assignment. One trade-off worth naming: GIT_SSH_COMMAND takes precedence over core.sshCommand, so an unattended run that needs its own ssh invocation must export GIT_SSH_COMMAND (the guard then leaves it alone). ~/.ssh/config is unaffected — ssh still reads it.

New git-env.test.ts covers the four cases: no terminal → all four set; TTY under CI → set; a person at a terminal → nothing set, so their credential helper still works; a caller's explicit value survives variable by variable.

Regression this PR introduced (found while verifying)

local-agent.test.ts "emits hint only once per sessionId" failed 3/3 isolated runs at c2b0872 and passed 3/3 at its parent. Cause: askViaTty awaited import('./utils/prompt.js') before declining, where the old code returned null synchronously on the hook path. Restoring the synchronous decline (static isInteractive import, dynamic import only when it will actually ask) makes it pass 4/4 isolated and 3/3 full-suite. The test remains timing-sensitive — I saw it flake once in ~5 full runs after the fix and could not reproduce it in six subsequent full runs, on this branch or with main's local-agent.ts — so it is worth hardening separately, not in this PR.

Test plan (re-run after the rebase)

• npx tsc --noEmit
• CI=true npx vitest run — 3781 pass, 1 skipped. The 3 failures are shell-profile.test.ts Windows cases on this macOS host (/var vs /private/var, zsh default), in a file this PR does not touch; same 3 on origin/main.
• npx vitest run --config vitest.e2e.config.ts — 40 files, 174 tests pass, 26 skipped.

Real CLI, end to end (built from 2dc23c2)

Isolated HOME, a git wrapper on PATH recording the environment every git child inherited, throwaway private GitHub repo, ambient GIT_ASKPASS / SSH_ASKPASS stripped first. Paths redacted.

1. init, GitHub, no credential, stdin closed   exit=1 in 1s, message names GITHUB_TOKEN
2. init, GITHUB_TOKEN exported                 exit=0 in 8s, repo cloned, hooks written
3. init on a pseudo-terminal, CI=true          exit=0 in 12s  ← pty + CI still counts as unattended
4. pull / doctor / uninstall --force in (2)    exit=0 / exit=1 (sandbox has no project-scope
                                               .claude dir — unrelated to this PR) / exit=0
5. init, TGit, fake gf (login sleeps 300s),
   TGIT_TOKEN exported                         exit=1 in 0s, message names `gf auth login`,
                                               login never spawned
6. git children in 1–5                         GIT_TERMINAL_PROMPT=0 GIT_ASKPASS=echo
                                               GIT_SSH_COMMAND='ssh -o BatchMode=yes'
                                               GCM_INTERACTIVE=never
7. interactive control (pty, no CI)            teamai sets none of the four

Real clones under exactly that environment, to show the new variables close prompts without breaking credentials that work:

https, osxkeychain helper, private repo   exit=0 in 1s   ← helper path untouched
ssh, BatchMode, private repo              exit=0 in 2s   ← agent/key auth untouched
https, wrong token                        exit=128 in 1s
https, no credential at all               exit=128 in 0s  "fatal: unable to get password from user"

Not run: gitlab and the cnb / tgit logins against their real CLIs (no credentials for a live instance here). Their guards sit in front of the spawn and are covered by unit tests; the TGit path above used a fake gf that reproduces the hang.

[github-actions]

Findings

• [P1 blocking] src/utils/git-env.ts:32 unconditionally sets GIT_SSH_COMMAND for unattended runs, which overrides existing global/repository core.sshCommand configuration. Valid setups relying on a custom key, SSH binary, or wrapper will fail during init, pull, or push. Add batch mode without replacing the configured SSH command.
• [P1 blocking] PR description, Test Plan: CI=true npx vitest run is checked as passing but explicitly reports three failures. The trusted repository rules require every Test Plan item to actually pass before PR; provide a clean full-suite run or fix the failures.

The description otherwise contains a sufficiently detailed real-CLI end-to-end verification record.

[SaulMoro]

Round 2 — both findings fixed in 9c22d74. Branch is already on top of origin/main (9ce8a0e), no rebase needed.

P1 — GIT_SSH_COMMAND replaced core.sshCommand

Right, and the note I left in round 1 ("callers who need their own ssh must export GIT_SSH_COMMAND") put the burden on the wrong side: a deploy key configured in core.sshCommand is a working setup that this PR would have broken. Batch mode is now appended to what is configured instead of replacing it.

core.sshCommand unset                          → ssh -o BatchMode=yes
core.sshCommand = ssh -i ~/.ssh/deploy_key -F … → ssh -i ~/.ssh/deploy_key -F … -o BatchMode=yes
core.sshCommand already names BatchMode         → left exactly as configured (yes or no is the caller's call)
GIT_SSH_COMMAND exported by the caller          → untouched, and the config read is skipped entirely

Cost: one git config --get core.sshCommand per unattended run, and only when GIT_SSH_COMMAND is unset. It is the last thing applyNonInteractiveGitEnv() does, so the three cheap variables are set even if git is missing from PATH (then there is no git child to protect either, and the fallback is plain ssh).

Verified with the real CLI — a git wrapper on PATH recording what each git child inherited, isolated HOME carrying the core.sshCommand under test:

none        SSH_COMMAND=ssh -o BatchMode=yes
configured  SSH_COMMAND=ssh -i ~/.ssh/deploy_key -F /etc/ci -o BatchMode=yes
caller-wins SSH_COMMAND=ssh

(The probe itself — git config --get core.sshCommand — is the one git child that runs before the variable exists. It opens no connection.)

P1 — the Test Plan claimed a pass while reporting three failures

Fair, and the explanation I gave for those three was wrong on top of it. They were not a /var vs /private/var comparison: detectShellProfile checks SHELL before the platform branch (deliberately — MSYS2/Cygwin zsh on Windows), and those three Windows cases were the only ones in the file that never stubbed SHELL. Run from a zsh login shell they resolved .zshrc and never reached the Windows branch at all. CI runners use bash, which is why all four matrix legs were green. They stub SHELL now, exactly as their siblings already did.

That left one more source of noise: the once-per-session binding-hint markers in local-agent.test.ts live in os.tmpdir() under a single shared key, so a leftover marker from one test decided whether the next test emitted a hint, and parallel runs competed for the same two paths. Each test now gets its own temp directory, which makes the markers per-test by construction.

CI=true npx vitest run → 3788 passed, 1 skipped, 0 failures, five consecutive runs, exit 0. npx tsc --noEmit clean, npx vitest run --config vitest.e2e.config.ts → 174 passed / 26 skipped. The PR description's Test Plan is updated to say this, and the stale round-1 claims in it (the TGIT_TOKEN line in the summary diff, the GIT_TERMINAL_PROMPT-only note) are corrected.

Docs updated for the composed ssh command: docs/usage-guide.md, docs/usage-guide.zh-CN.md, CHANGELOG.md.

One disclosure: shell-profile.test.ts and local-agent.test.ts are test-isolation fixes outside this PR's subject. I made them because the alternative was asking you to trust a suite that fails for reasons unrelated to the change — both are test-only, and neither weakens an assertion.

[github-actions]

• [P1 blocking] src/utils/git-env.ts:47 — Do not derive a process-wide GIT_SSH_COMMAND from the launch directory. git config --get core.sshCommand reads the current repository’s local config, then the environment variable overrides core.sshCommand for every later Git operation. Running teamai pull from repo A can therefore force repo A’s SSH key/wrapper onto the managed team repo; conversely, the default value can suppress the managed repo’s own core.sshCommand. Set batch mode per Git child/repository instead of globally.
• [P1 blocking] src/__tests__/shell-profile.test.ts:52 — The required unit-test run is not green, and the explanation is inaccurate. The PR description reports three failures while claiming shell-profile.test.ts is unchanged, but this PR modifies that file. The repository requires test-plan items to actually pass; provide a successful run or fix/revert the relevant changes before merge.
• [P1 blocking] src/__tests__/local-agent.test.ts:28 — Remove unrelated test cleanup changes. The temp-directory isolation rewrite and the shell-profile test edits do not trace to preventing unattended provider-login hangs, violating the surgical-change rule. Move them to a separate PR unless they are demonstrably required for this fix.

The description does include substantial unit and real-CLI end-to-end evidence, so it is not missing an e2e record.

[SaulMoro]

Round 3 — all three findings addressed in b7ae874, and the branch is rebased on origin/main (109b334), which also clears the conflict banner: #724 moved the TGit login section into provider-tgit.md, so my correction moved with it.

P1 — a process-wide GIT_SSH_COMMAND derived from the launch directory

Correct, and worse than the round-2 finding it was meant to fix. GIT_SSH_COMMAND overrides core.sshCommand for every later git operation, not only the repository the value came from, so teamai pull in repo A would have pushed A's key or wrapper onto the managed team repo, and the plain default would have suppressed a core.sshCommand the team repo configured for itself. Prompt suppression has no business reaching a repository's transport.

The variable and the git config read are gone. What stays are the three that name a prompt and nothing else, so one value is right for every repository a run touches:

GIT_TERMINAL_PROMPT=0   git's own username/password question on the terminal
GIT_ASKPASS=echo        the askpass chain, a GUI dialog on a desktop session
GCM_INTERACTIVE=never   Git Credential Manager's own window

ssh is now documented as the caller's to close, where the setting belongs: git config core.sshCommand 'ssh -o BatchMode=yes' on the repository, or GIT_SSH_COMMAND for one run. I measured the exposure before narrowing the promise — with stdin closed, ssh's /dev/tty read hits EOF and the connection fails in about a second, so the unattended paths this PR is about never depended on the flag:

ssh -i <passphrase-protected key> … on a pty, stdin closed   exited in 1s

End to end, with a git wrapper on PATH recording what each git child inherited and a core.sshCommand planted in the sandbox HOME:

core.sshCommand unset       GIT_SSH_COMMAND=<unset>   TERMINAL_PROMPT=0 ASKPASS=echo GCM=never
core.sshCommand = ssh -i …  GIT_SSH_COMMAND=<unset>   ← the repo's own setting governs
GIT_SSH_COMMAND=ssh         GIT_SSH_COMMAND=ssh       ← caller's value passes through

P1 — unrelated test changes

Agreed, and removed: the shell-profile.test.ts and local-agent.test.ts isolation edits are reverted. Neither traces to preventing an unattended provider-login hang, and I should not have folded them in.

P1 — the unit-test run

The description's Test Plan is rewritten to a run that is actually green: 3786 pass, 1 skipped, 0 failures, three consecutive runs on the rebased branch, launched the way CI launches it (SHELL=/bin/bash). CI's four matrix legs are green on the same source.

On the earlier failures, so the record is straight: they were never a /var vs /private/var comparison, and shell-profile.test.ts was unchanged when the first description claimed so — the round-2 edit came later, and is now reverted. The real cause is that detectShellProfile reads SHELL before its platform branch, so under a zsh login shell three win32 cases resolve .zshrc and never reach the branch they test. That is a pre-existing dependency in a file this PR does not touch; it is noted in the Test Plan and left for its own PR rather than widened into this one.

Coverage in this round

tsc --noEmit clean; unit suite as above; vitest run --config vitest.e2e.config.ts 174 pass / 26 skipped on this exact source (the rebase that followed carried only skill documentation). Real CLI, built from this branch: GitHub with no credential fails in 1s naming GITHUB_TOKEN; GitHub with GITHUB_TOKEN clones and completes; a pseudo-terminal with CI=true behaves as unattended; TGit with a fake gf whose login sleeps fails in 0s naming gf auth login; GitLab was exercised against a live instance with GITLAB_TOKEN; and the three ssh cases above. The cnb login against its real CLI is the one guard still covered only by unit tests — it sits in front of the spawn, like the others.

[github-actions]

Findings

• [P1 blocking] Update the provider authentication reference. docs/providers.md:122 still states that teamai init runs gf auth login unconditionally, but this PR now refuses to do so without an interactive terminal. This violates the repository rule requiring every affected document to reflect behavior changes. The GitHub/CNB auto-login wording at docs/providers.md:77 and docs/providers.md:152 should likewise clarify the interactive-only condition.
• [P2 non-blocking] Correct the PR summary’s claim that SSH BatchMode is closed. src/utils/git-env.ts:16 explicitly leaves SSH prompts enabled, so an unattended SSH clone can still wait for a key passphrase or host confirmation. The later Notes section describes this accurately, but the opening summary and “every git prompt” framing do not.

The PR description contains a detailed test plan and real-CLI end-to-end verification record; no testing-description blocker.

[SaulMoro]

Round 4, both fixed in 3b4d24c (branch rebased on origin/main 9d8ed1f, so the conflict banner is clear again).

P1 — docs/providers.md. Missed file, and the rule is clear that it should have moved with the behaviour. All three auto-login descriptions now say the login only happens in an interactive terminal, and what an unattended run gets instead: GitHub and CNB name the token to export, TGit names a prior gf auth login and says why no token substitutes for it (TGIT_TOKEN is REST-API-only and git.woa.com's git endpoint rejects it). GitLab and GitCode already described token auth, so they are unchanged.

P2 — the summary's framing. Corrected. The opening paragraph now states the limit where a reader meets it, instead of leaving it to the Notes: the git environment closes git's own questions (terminal prompt, askpass dialog, credential manager window), and ssh is explicitly not covered, because its batch flag is only reachable through GIT_SSH_COMMAND and that would override each repository's core.sshCommand. The diff block in the summary says the same.

Docs-only change since the last round; npx tsc --noEmit clean.

[github-actions]

Findings

• [P2 non-blocking] src/providers/github/gh-cli.ts:229 and src/providers/cnb/cnb-cli.ts:179 misdiagnose invalid exported tokens as missing credentials. When a token exists but verification fails, the new guard tells users to export the same variable again. Detect token presence and report that it was rejected, similar to the GitCode provider.
• [P2 non-blocking] src/utils/git-env.ts:17 deliberately leaves SSH interactive. An initial SSH clone cannot rely on repository-local core.sshCommand because the repository does not exist yet; with a pseudo-TTY plus TEAMAI_NONINTERACTIVE=1, host-key or passphrase prompts can still hang. Apply -c core.sshCommand="ssh -o BatchMode=yes" to the individual clone invocation rather than globally overriding later operations.

The PR description includes a detailed test plan and real-CLI end-to-end verification, so no testing-description blocker.