[Feature]: don't cap hook-running git commands at 30s — pre-push hooks are killed mid-run

[sgtz]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/server

Problem or use case

git push from T3 Code is capped at 30 seconds, so any repository whose pre-push hook does real work cannot push from the app.

Up front, so it is weighted correctly: this is derived from reading the source at d3037064, not from a live reproduction in the app. Repro steps are below and I would be happy to confirm them if that is useful. Everything about the git invocation path below is quoted from the tree.

The good news first, because it is what makes this worth fixing rather than working around: T3 Code spawns the real git binary, so it inherits hooks correctly.

// apps/server/src/vcs/GitVcsDriverCore.ts:730
ChildProcess.make("git", commandInput.args, { cwd, env })

No isomorphic-git / simple-git / nodegit / dugite in any package.json, and zero occurrences of --no-verify, noVerify, or hooksPath across apps/server/src, packages/shared/src, apps/web/src, apps/mobile/src. That is the right design and it is why the app is usable in hook-gated repos at all.

The problem is the timeout applied on top:

// apps/server/src/vcs/GitVcsDriverCore.ts:40
const DEFAULT_TIMEOUT_MS = 30_000;

// :712
const timeoutMs = input.timeoutMs ?? DEFAULT_TIMEOUT_MS;

// :815
Effect.timeoutOption(timeoutMs)

pushCurrentBranch calls runGit on all three of its paths with no timeoutMs override, so every push inherits the 30 s default:

// :1883 / :1949 / :1986
yield* runGit("GitVcsDriver.pushCurrentBranch.push", cwd, ["push"]);

git push does not return until pre-push exits. So a hook that runs anything substantial is killed at 30 s.

There is no escape hatch today. timeoutMs is internal plumbing with hardcoded call-site values (5_000, 20_000) and the 30_000 default. It is not reachable from user settings, and the only git-related env vars read anywhere in apps/server/src are GIT_ASKPASS, GIT_SSH, and GIT_TERMINAL_PROMPT.

Two things make the failure worse than a plain error:

1. It is misattributed. The timeout kills the spawned git, so the UI reports a failed push. Nothing indicates that the push itself was fine and a hook was interrupted, so users will reasonably suspect their remote, credentials, or network.
2. It can leave an orphan. Killing git does not necessarily reap the hook's own children. A hook that spawns a build or test runner can be left running, detached, holding CPU and locks. In our case that process is a ~16-minute merge gate.

How common is this? Any repo using husky, lefthook, or a hand-installed pre-push that runs more than a lint. Typical examples that exceed 30 s: a test suite, a type-check on a large monorepo, a build, or a CI-style gate. This is not an exotic configuration.

Prior art in this repo: #4296 is the same class of defect — a hardcoded 5 s fetch timeout, whose overrun filled disks with orphaned tmp_pack_* files. Hardcoded git timeouts appear to be a recurring source of trouble.

Repro

1. In any repo, install a pre-push hook containing sleep 45; exit 0.
2. Push that branch from a terminal — succeeds after ~45 s.
3. Push the same branch from T3 Code — expected: killed at 30 s and surfaced as a push failure.
4. Optional, for the orphan case: make the hook sleep 600 & a child, then check whether the child survives the timeout.

Proposed solution

In rough order of how much they solve, though any one of them unblocks the case:

1. Do not apply a wall-clock timeout to hook-running git commands. push, commit, merge, rebase and am all run user hooks of unbounded duration. A fixed timeout on them is a category error: the app cannot know how long a user's hook legitimately takes. Read-only queries (status, rev-parse, log) are where short timeouts genuinely belong, and they already have their own tighter values.

2. If a bound is wanted, use an inactivity timeout, not a total one. Reset the timer on stdout/stderr output rather than capping total duration. That still catches a genuinely wedged process while letting a 10-minute hook that is printing progress run to completion. This is strictly better than any fixed number, because it does not require guessing.

3. Make it configurable, with a generous default for hook-running commands. A per-repo or global setting — git.commandTimeoutMs, or something narrower like git.hookTimeoutMs — would be enough. Even a plain env override (T3_GIT_TIMEOUT_MS) would unblock every affected user immediately, and the codebase already reads T3_-prefixed env vars elsewhere.

4. Regardless of the above: surface the cause, and clean up children. When a git command is killed by the timeout, say so explicitly — "git push exceeded the 30s limit; a pre-push hook may still be running" beats a generic push failure. And kill the process group, so an interrupted hook does not leave detached children behind (the #4296 lesson).

Why this matters

• It silently excludes an entire class of repository. Teams with a real pre-push gate — exactly the teams with enough process to want multi-agent orchestration — cannot use the one-button commit/push/PR flow, which is a headline feature.
• The failure teaches the wrong lesson. Because it presents as a push failure, the natural user response is to retry, check credentials, or disable the hook. Disabling the hook is the worst outcome available: it removes the safety net rather than the obstacle, and it does so quietly.
• It scales badly with the product's own premise. T3 Code's value is running several agents at once. More agents means more pushes, which means more encounters with this limit, and more orphaned hook processes competing for the same machine.
• The fix is small and the design is already right. Shelling out to real git is the hard part and it is done. This is a timeout policy on top of a correct foundation.

Smallest useful scope

Exempt push from DEFAULT_TIMEOUT_MS — either no timeout, or a much larger one — leaving every other command exactly as it is today.

That is a change to the three runGit call sites in pushCurrentBranch (GitVcsDriverCore.ts ~1883 / ~1949 / ~1986), or a single change to the default resolution at :712. It fixes the reported problem with essentially no blast radius, and commit/merge/rebase can follow later if anyone hits them.

An even smaller stopgap, if a policy discussion is needed first: honour a T3_GIT_TIMEOUT_MS env override at :712. One line, no UI, unblocks affected users immediately.

I am happy to open a PR for whichever shape you prefer — say which and I will follow the repo's conventions.

Alternatives considered

• Patch a fork. Rejected. The change is one line, but a fork means owning the build, signing and update channel for a desktop app across five platforms, against a fast-moving upstream. The maintenance cost dwarfs the patch by orders of magnitude — which is why this is an upstream request rather than a private fix.
• Make our hook finish in under 30 s. We are in fact doing this for the common case (classifying which pushes can skip the gate entirely), and it is good practice regardless. But it cannot be the general answer: the slow path exists precisely because some changes genuinely need the full gate, and no amount of optimisation makes an honest 16-minute verification fit in 30 seconds.
• --no-verify from the app. Rejected outright, and I would argue against it as a feature. It converts a safety mechanism into an opt-out, and the whole reason the hook exists is that unverified pushes are expensive to undo.
• Push only from the terminal. This is our current workaround and it works, but it means the app's headline commit/push/PR button is unusable for the repository where we most want it.
• A git-level config. There isn't one — git has no client-side hook-timeout setting. The bound is purely T3 Code's.

Risks or tradeoffs

• Removing the timeout entirely risks a hang. If a hook waits on input, the command never returns. Two mitigations, both cheap: GIT_TERMINAL_PROMPT=0 is already set in this codebase, and an inactivity timeout (proposal 2) bounds a silent process without capping a productive one.
• Long-running commands need UI affordances. A 10-minute push should show progress and be cancellable, rather than appearing frozen. Hook output is already available on the spawned process's stderr, so surfacing it may be mostly a plumbing question. This is arguably the most valuable part of the change for users, and the part I would least like to see skipped.
• A configurable timeout is one more setting. Scoping it to hook-running commands rather than all git commands keeps the surface small; alternatively, proposal 1 or 2 needs no setting at all.
• Do not fix this by cancelling the hook and pushing anyway. Worth stating explicitly because it is a tempting shortcut: it would turn a visible failure into an invisible one, which is strictly worse than the current behaviour.

[devchaudhary24k]

Adding a live-use confirmation from another affected setup: the thread-header Push action fails consistently when the repository's pre-push build/CI gate runs longer than 30 seconds. This matches the current GitVcsDriverCore wall-clock timeout described above.

I’m preparing a focused fix that exempts explicit git push commands from the shared 30-second deadline while leaving bounded background/read operations unchanged. The regression test will use the Effect test clock, so it proves a push can exceed 30 seconds without adding a slow test.