[Bug]: Custom Antigravity binary fails with wrapper scripts (.cmd/.bat) due to rigid localharness_external sibling check

Open
#12,752 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
typescript
Domain
desktop

Research direction

Start at resolveSiblingExternalBinary and the Windows ACP process-spawning path; trace the custom binary health check with a .cmd/.bat wrapper and the managed tool directory fallback. Done means custom wrappers can locate localharness_external through the fallback and ACP JSON-RPC completes reliably through standard I/O pipes.

Written by the indexing model from the issue text.

Description

accepted bug via-triage
Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/desktop

Steps to reproduce
  1. Create a custom wrapper script on Windows (e.g., agy-wrapper.cmd or a proxy executable) to wrap agy_acp_server.exe (e.g., to set custom environment variables or isolate temp directories).
  2. Point Antigravity's custom binary path (binaryPath) to this wrapper.
  3. Observe health check failure:
    The custom Antigravity executable or its localharness_external sibling is missing or not executable.
  4. If a placeholder localharness_external.cmd or copy is placed alongside it, the health check fails or hangs with:
    Unavailable · Antigravity could not complete its local health check.
Expected behavior
  1. T3 Code should allow custom binaries/wrappers without strictly requiring localharness_external.exe to reside in the exact same directory (e.g., fall back to the managed tool directory for localharness_external).
  2. Windows process spawning for ACP should reliably handle standard I/O pipes (stdin/stdout) when invoking .cmd or proxy executables.
Actual behavior

resolveSiblingExternalBinary checks path.join(path.dirname(binaryPath), "localharness_external" + ext). If missing, it immediately rejects the binary. If present, standard I/O pipe inheritance through Windows cmd.exe /c breaks the ACP JSON-RPC handshake.

Impact

Minor bug or occasional failure

Version or commit

0.0.42 (and main)

Environment

Windows 11 x64, T3 Code Desktop 0.0.42

Logs or stack traces
Not found: The custom Antigravity executable or its localharness_external sibling is missing or not executable.
# Or:
Unavailable: Antigravity could not complete its local health check.
Workaround

Must invoke the raw unpacked agy_acp_server.exe directly from its directory with localharness_external.exe present alongside it; cannot use wrappers or intermediate launchers.

Suggested Fix
  1. Make localharness_external resolution check the bundled/managed tool directory as a fallback when binaryPath is a custom path without its own localharness_external.
  2. Ensure stdio options and process spawning on Windows correctly pipe stdio when binaryPath has a .cmd or .bat extension.
Dominant language
TypeScript
Stars
23.3k
Forks
6k
Avg merge
10h 57m
Merged PRs (30d)
365

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.