# 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):

```jsonc
{
  "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](https://discord.gg/DSa65w8wuf).
