v0.39.2

v0.39.2: no more "bridge keeps getting killed", configurable timeouts, quieter sandboxes

A patch centered on bridge stability: a passive status poll can no longer kill the bridge out from under your work. Plus the bridge timeout and restart threshold are now tunable for slow filesystems and multi-window setups, and AFT no longer looks broken in restricted sandbox environments.

The sidebar status poll no longer kills a busy bridge (#117)

The TUI sidebar polls the bridge for status roughly every 1.5 seconds. When the bridge was busy with real work — say a background Code Health scan kicked off by your edits — those polls queued behind it and timed out. Two timed-out polls tripped the "bridge looks hung, restart it" rule, which killed and respawned the bridge — aborting the edit or read you were actually waiting on. The agent then saw "the bridge keeps getting killed" and retried straight back into the same trap.

A passive status poll timing out means the bridge is busy, not hung, so it no longer counts toward the restart rule and now falls back to the last cached status immediately instead of blocking. Your real work is never interrupted by a health check again. (Most visible on Windows and large repos, where the background scan runs longer, but it was cross-platform.)

Configurable bridge timeout and hang threshold

Related to the above: on slow filesystems (WSL/DrvFs, NFS, network mounts) the aft binary's cold start and file walks can legitimately exceed the built-in 30-second request timeout, and combined with the fixed "restart after 2 consecutive timeouts" rule this produced a restart loop. The same fixed threshold also bit setups where several editor windows share one bridge process. The #117 fix removes the most common trigger (passive polls); these knobs let you tune the remaining behavior for genuinely slow environments.

Two settings are now configurable in aft.jsonc (defaults unchanged, so nothing changes unless you opt in):

{
  "bridge": {
    "request_timeout_ms": 30000,  // raise on slow filesystems
    "hang_threshold": 2           // raise when many windows share one bridge
  }
}

These are user-level settings (a project config can't change them, since they govern the bridge's restart safety and your machine's transport budget).

Graceful degradation in restricted sandboxes

• cpuinfo noise (#97): in some sandboxes, ONNX Runtime's bundled CPU-detection library logs Error in cpuinfo: failed to parse processor information from /proc/cpuinfo. That's a benign third-party message, not an AFT failure — AFT never depended on /proc/cpuinfo. It's now filtered so it doesn't surface as an AFT error; genuine errors still show.
• watcher unavailable (#111): when the filesystem watcher can't attach (often an inotify limit in sandboxes), AFT already kept working — it just lost live detection of external file changes. It was presented as an alarming error; it now reads as an honest soft degradation: "file watcher unavailable; continuing without live external-change invalidation."

---

Thanks to @herjarsa for the bridge-timeout investigation and the original implementation it grew from.

Questions or feedback? Join us on Discord.