Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: Injected browser rule forbids falling back after preview_open succeeds, so agents stop and ask the user which browser to use

Aperta Adatta ai principianti
  • Qualcosa non va?
#16,404 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@juliusmarminge ci sta già lavorando.

Dal 7/10/2026.

  • #16956 di @juliusmarminge — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
82/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
typescript
Ambito
backend

Direzione di ricerca

Inizia da apps/server/src/provider/T3OrchestrationInstructions.ts e leggi la regola del browser iniettata. Aggiornala per consentire un fallback allo strumento browser dopo ripetuti errori delle chiamate di anteprima, senza rimuovere la preferenza generale per gli strumenti di anteprima T3; il lavoro è completato quando gli agenti possono passare da uno strumento all’altro senza chiedere e segnalare l’errore di anteprima grezzo.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Filed by Claude (Opus 5.5, running inside T3 Code) on behalf of @janpilu, at their request. The investigation was done by agents on their machine. We reviewed the last week of our T3 threads.

Before submitting
  • I searched existing issues and did not find a duplicate. The failures that set this off are tracked in #13540 (failover after a timeout), #16264 (a timed-out evaluate keeps running), #13990 (sandboxed_renderer.bundle.js failed to run) and #15336 (errors reduced to "failed on client"). This report is about how agents react to those failures. It isn't about the failures themselves.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server (src/provider/T3OrchestrationInstructions.ts)

Summary

T3 injects this browser rule into every provider session:

Use an alternative browser system only when the T3 preview tools are absent, the user explicitly requests another browser, or preview_open returns an explicit unsupported/unavailable error.

None of the three conditions covers the common failure: preview_open works, then later preview calls keep failing. Examples are calls that time out, a tab that lands on chrome-error://chromewebdata/, recordingStop failed on client …, or a different client ID answering after the session moved to another host (#13540). In that state the agent may not use Playwright or any other browser unless the user "explicitly requests" it. So unattended agents stop and ask the user which browser to use.

The person being asked usually can't answer. Our verification agents asked four times in three days, with questions like "Close the extra client?" and "Leave only the development-machine client connected?". Their answers were "what does this mean" and "no idea what you are talking about". The same thing happened to a coworker on a different machine, because the rule is injected for everyone. A project's own AGENTS.md or skill text that allows Playwright doesn't help: agents read the injected developer instruction as taking priority, and project text doesn't count as the user explicitly asking.

Steps to reproduce
  1. Give an agent a task that requires browser verification. Allow "T3 preview tools or Playwright" in the project instructions, and don't mention a browser in the prompt.
  2. Make preview calls fail after a successful preview_open. The simplest way is #13540 with two desktop clients connected: preview_evaluate with new Promise(() => {}) times out, and later calls go to the other host.
  3. Watch the agent.
Expected behavior

After a bounded number of failed preview calls (for example, two failures on the same step), the agent may switch to another browser tool. It says so and quotes the raw preview error, and it doesn't need to ask. Alternatively, the rule says plainly that project or skill instructions can authorise a fallback.

Actual behavior

The agent stops the turn and asks the user for permission to switch browsers. Unattended pipelines stall until someone answers a question they don't have the context for. In one case, on 2026-10-05, the agent asked to switch because it thought its recordings were frozen. They weren't: its own frame-sampling script was returning frame 0 for every timestamp. The same rule meant even a mistaken diagnosis ended up as a question to the user.

Suggested change

Add a fourth condition along these lines: "…or after preview calls on an already-open tab have failed twice for the same step (timeout, chrome-error://, a failed recording stop, or a different client answering). In that case, state the raw error and switch without asking." Keep the general preference for T3 preview tools as it is.

Impact

Major degradation or frequent failure. Our verification pipeline stalls with an unanswerable question every few runs. Until #13540 and #16264 ship, this rule is what turns their failures into blocked turns.

Version

Nightly 0.0.46-nightly.20261005.2667 (37de6cbde65c), macOS 26.6.2 arm64. The instruction text is in apps/server/src/provider/T3OrchestrationInstructions.ts. In the shipped bundle it's binCli-*.mjs.

Lingua principale
TypeScript
Stelle
24.8k
Fork
6.4k
Merge medio
13h 9m
PR unite (30g)
271

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingdotgg/t3code

Tutte le issue di pingdotgg/t3code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.