[Finn763]

Issue for this PR

Closes #54974

Type of change

• Bug fix
• Refactor / code improvement

What does this PR do?

The TUI builds its client with plain OpenCode.make(...), so its requests inherit Bun's default five-minute fetch deadline. A plugin command whose execute stays pending (or a long session.shell call) is accepted by the server, but the client transport drops the request at ~5-6 min — the server logs 499, the UI restores the composer and navigates away, and the executor keeps running.

This PR gives the TUI client timeout: false at both construction sites (the initial client and the service reconnect path), matching what run and mini already do.

Maintainer follow-ups folded in:

• One shared helper. The same fetch(request, { ...init, timeout: false }) wrapper lived in packages/cli/src/run/run.ts and packages/cli/src/mini.ts, and would have been a third copy here. It now lives once in @opencode/util/no-timeout-fetch (both cli and tui already depend on @opencode/util) and is used by run, mini and the TUI.
• Shell failures surface. In an existing session, session.shell was fired with no .catch, so a rejected shell command became an unhandled rejection with no feedback. It now uses the same fail(...) toast + composer restore as the session.command path (new sessions still go through newSession.recover).

Scope note: Promise executors still keep running with no cancellation signal; that belongs with the command lifetime/cancellation work (#53913 / #53914).

How did you verify your code works?

• Original reproduction from the issue (author): on the base the TUI drops the command by t+380s; on this branch it stays through t+400s and completes once released.
• packages/util/src/no-timeout-fetch.test.ts: the helper preserves method/headers/body and still honours an abort signal.
• packages/tui/test/prompt-shell-failure.test.tsx: a failing session.shell in an existing session shows "Failed to run shell command" and restores the composer (fails with an unhandled Shell unavailable error without the fix; 20/20 with --rerun-each).
• packages/cli/test/mini-timeout.test.ts (with BUN_CONFIG_HTTP_IDLE_TIMEOUT=1) still passes through the shared helper.
• bun run check clean.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

[opencode-agent]

This fixes the problem. I ran the #54974 reproduction (a plugin /hang command that stays pending, simulated model) from source on the base and on this branch.

• Base: by t+380s the TUI had dropped the request, returned to the home screen and put /hang back in the composer, while the plugin's execute was still running.
• This branch: the TUI stayed on the session past t+400s, and the command finished cleanly once released (~380s).

The packages/tui test passes and its typecheck is clean. The wrapper matches the one in packages/cli/src/run/run.ts, and it covers both places the TUI builds its client (startup and reconnect).

Public API: unchanged.

One point: the added test can be dropped (see the inline comment).

Related: #50135

[opencode-agent]

This test can be dropped so the change stays minimal. It replaces globalThis.fetch only to check a one-line spread. It doesn't show that the TUI client actually uses the wrapper, or that a request survives past Bun's deadline.

[BrickerP]

Verdict: would APPROVE (posted as COMMENT — no write access for formal approve)

Mirrors the existing CLI workaround in packages/cli/src/run/run.ts (fetch(request, { ...init, timeout: false } as BunFetchRequestInit) and wires it into both TUI OpenCode.make sites in packages/tui/src/app.tsx (startup options ~L215 and reconnect next ~L229). That is the right place for #54974’s transport drop: Bun’s ~5 min deadline, not a server limit.

Verified

• Wrapper { ...init, timeout: false } preserves signal / other RequestInit fields; only Bun’s fetch deadline is disabled — same hang-vs-abort tradeoff the CLI already accepted.
• Both construction paths covered; reconnect cannot fall back to a default-deadline client.
• Unit test checks timeout: false forwarding with and without init; type cast to BunFetchRequestInit matches run.ts.
• Scope correctly leaves Promise-executor cancellation to #53913 / #53914.

Non-blocking

• packages/cli/src/mini.ts createMiniConnection still builds a plain OpenCode.make (no timeout: false) — same shape as #50135; out of scope here but still a stock-client gap.
• Optional later: share one helper between CLI and TUI instead of duplicating the one-liner.

CI on head 0e6a6ba: check-duplicates / check-standards / check-compliance all success.

[Finn763]

Addressed in 7822a90: the wrapper test is dropped so the diff stays minimal -- it only pinned the one-line spread. The change is now just packages/tui/src/util/no-timeout-fetch.ts plus the two OpenCode.make sites, and the PR description is updated (your base/branch reproduction is cited there as the verification).

[thdxr]

Thanks @Finn763, this is merged as 52a10f5. Your fix, plus the clear reproduction in the issue, made this easy to land.

Before merging, I rebased it onto the latest dev and added two maintainer follow-ups:

• One shared helper. The timeout: false fetch wrapper now lives once in @opencode/util/no-timeout-fetch. The TUI, run and mini all use it, so there are no longer three copies. There is a small test showing that it keeps the request init and still honours an abort signal.
• Shell failures surface. In an existing session, a failed ! shell command used to reject with nothing handling it. It now shows a "Failed to run shell command" toast and puts your text back in the composer, the same way slash commands already did. A TUI test covers this.

Cancelling plugin executors is still out of scope here and stays with #53913 / #53914.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊