[Bug]: Windows 0.1.0 preview snapshots time out on loaded local page; same-tab reopen blocks for 11 minutes

Before submitting

Searched existing issues, including [Bug]: Windows snapshot/evaluate timeouts evict the shared server-browser host and abort another open #16921 (open), [Bug]: preview_snapshot can fail or time out on loaded pages and leave tab automation unusable #3713 (closed), and Client overlay wait shares the server's 15s deadline, so PreviewAutomationOverlayTimeoutError never reaches callers #8257 (closed).
This may overlap [Bug]: Windows snapshot/evaluate timeouts evict the shared server-browser host and abort another open #16921. Filing current Windows 0.1.0 evidence with a local-page control and an 11-minute recovery-call timeout; please consolidate if appropriate. A common root cause has not been established.
The evidence below comes from the original agent tool history and matching local server traces, collected on 21 October 2026. No new browser session was launched for this report.

Area

apps/desktop / apps/server preview automation

Summary

During a local game playtest, navigation returns a page title and loading:false, but repeated preview_snapshot calls fail with a 15-second timeout. Simple preview_evaluate calls subsequently time out too. Reopening the same tab with open:true blocks for approximately 11 minutes before failing.

This occurred in both incognito and default profiles. In the default profile, evaluation worked on a plain JSON resource before navigating to the game page. A newly created incognito tab remained unable to evaluate even 1+1 on that JSON resource. This suggests an automation/rendering reliability problem, but does not isolate a T3 bug from a page-triggered renderer stall.

Steps to reproduce / recorded sequence

This is an observed sequence against a private local app, not yet a minimal public or deterministic reproduction.

Serve the local Vite game at http://127.0.0.1:5230/, with a plain JSON resource at /config/play.json.
Call preview_open({profileId:"incognito", open:true, reuseExistingTab:false}). The response is available but reports visible:false.
Set a 1440 x 900 viewport. Navigate to the JSON resource. Evaluation succeeds and returns the page user agent and measured 1440 x 900 viewport.
Navigate to the game root. Navigation returns title:"RLHF Desktop", available:true, loading:false, visible:false, agent ownership, and no dialog.
Call preview_snapshot({includeImage:true, save:true}) twice. Both fail. A third call with {} fails the same way.
preview_status({}) still returns the title, loading:false, and available:true.
Call preview_open({tabId: TAB_A, open:true}) for that same tab. It fails with Preview automation open timed out after 660000ms.
A simple evaluation of title, visibility and body text times out after 15000ms.
Close TAB_A. Open a fresh incognito tab directly on the JSON resource with open:false. Snapshot and preview_evaluate({expression:"1+1"}) both time out.
Open another fresh tab in the default profile on the JSON resource with open:false. 1+1 succeeds with value 2. Reading JSON body text also succeeds after navigating to http://localhost:5230/config/play.json.
Navigate that default-profile tab to http://localhost:5230/. Navigation returns the game title and loading:false. Snapshot fails after 15000ms, then evaluating document.visibilityState + ' ' + innerWidth + 'x' + innerHeight also times out.

The default-profile control uses localhost rather than 127.0.0.1 for the final game navigation, so this is not a fully matched profile/origin experiment.

Expected behavior

A loaded page should remain inspectable. If inspection is blocked by a renderer, capture stage, or desktop-overlay readiness problem, return a specific actionable error and keep recovery bounded. Reopening a tab should recover or fail promptly rather than block the agent for 11 minutes.

Actual behavior

Repeated generic snapshot/evaluation timeouts interrupt the playtest; metadata/status can report the tab available while inspection is unusable. Reopening the original tab does not recover it within the tool's long timeout.

Error: Preview snapshot failed: Preview automation snapshot timed out after 15000ms.
Error: Preview automation evaluate timed out after 15000ms.
Error: Preview automation open timed out after 660000ms.

Impact

Major degradation or frequent failure. The agent could not inspect the game through the preview and moved toward the repository's external-browser fallback. Successful completion of that fallback was not verified as part of this report.

Version or commit

T3 Code (Beta) 0.1.0. Installed executable FileVersion: 0.1.0; ProductVersion: 0.1.0.0. Release commit SHA not verified.

Environment

Windows 11 Enterprise, version 10.0.26200, build 26200.
Original testing provider/model: claudeAgent / claude-opus-5-5, as recorded by T3 thread metadata.

Page user agent from the original incognito tab:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) T3CodeBeta/0.1.0 Chrome/152.0.7977.130 Electron/44.4.5 Safari/537.36

This identifies the original tab as Electron/Chromium 152. A Chrome headless shell 154 process also exists on this machine, but it is not established as the engine of the failed tab.
UI failures were viewed from an Android phone; browser automation was running in the Windows environment, not on the phone.

Logs or stack traces

Selected server spans, with UTC start times on 2026-10-21. These are measured outer MCP call durations, distinct from the 15000ms/660000ms values in the errors:

00:54:20.121  JSON-page evaluate success             49.9723 ms
00:55:33.495  snapshot timeout                    16014.5805 ms
00:55:52.467  snapshot timeout                    16005.7967 ms
00:56:14.239  snapshot timeout                    16020.9675 ms
00:56:35.472  same-tab preview_open timeout      661015.2878 ms
01:07:41.085  evaluate timeout                    16034.4406 ms
01:08:15.175  fresh incognito snapshot timeout    16020.6406 ms
01:08:33.583  fresh incognito 1+1 timeout          16019.8403 ms
01:08:58.131  default-profile 1+1 success             47.5269 ms
01:09:13.755  default-profile JSON read success       71.1954 ms
01:09:36.686  default-profile game snapshot fail  16021.9267 ms
01:09:55.656  default-profile game evaluate fail  16013.7323 ms

Snapshot spans include this warning event:

["preview snapshot failed", {"operation":"snapshot","errorTag":"PreviewAutomationTimeoutError","failureCount":1}]

The enclosing failed-tool spans have exit:{"_tag":"Success"} in the server trace; the tool history records the errors. Each listed snapshot warning reports failureCount:1, despite successive failures in the same workflow.

Investigation limits and workaround

No proof of host eviction, overlay deadline collision, GPU fault, or game-code cause was obtained.
The first open:true response nevertheless reported visible:false. This is a diagnostic clue, not proof that hidden visibility caused the stall.
The third snapshot omitted image options; includeImage:false was not explicitly tested, and no claim is made that image capture was bypassed.
Incognito recreation did not recover inspection in this run. A fresh default-profile tab briefly restored evaluation on a JSON resource, but failed after loading the game.
No T3 reinstall, update, GPU-setting change, source patch, or full app restart was attempted for this report.
Private game source, full application logs, local filesystem paths, account details, and session identifiers are omitted.

References

[Bug]: Windows snapshot/evaluate timeouts evict the shared server-browser host and abort another open #16921 — related Windows snapshot/evaluation timeouts and recovery/host behavior; this report does not establish its host-eviction mechanism.
[Bug]: preview_snapshot can fail or time out on loaded pages and leave tab automation unusable #3713 — earlier loaded-page snapshot failure followed by unusable evaluation; closed, included for symptom history.
Client overlay wait shares the server's 15s deadline, so PreviewAutomationOverlayTimeoutError never reaches callers #8257 — earlier hidden-overlay/deadline diagnostic problem; closed, included because visibility remained false here. Its historical diagnosis is not assumed to apply to 0.1.0.

Note

Grok responding on behalf of Julius.

Thanks for the careful write-up, and for flagging the limits of the evidence. As you note, this doesn't yet separate a preview automation problem from the page stalling its own renderer. It also overlaps two open reports: #16921, where Windows snapshot and evaluate timeouts take down the shared browser host, and #16567, where a snapshot on a background tab never returns and blocks later actions on that tab. Your tabs reported visible:false throughout, which matches #16567's setup.

On the 11-minute wait: the error text comes from PreviewAutomationTimeoutError (packages/contracts/src/previewAutomation.ts:944-952), which reports whatever timeout the operation was given. I couldn't find 660000ms as a fixed constant on main.

To tell whether this is one of those or something separate, could you:

Reproduce against a small public page, or a minimal local page, that shows the same timeouts.
Retry with includeImage: false and with the tab opened visible.
Retest after a full app restart, and attach the server trace lines for the snapshot, evaluate and open calls.

Follow-up to #22594 (comment): the owner confirms they had already restarted the app, and asked us to check earlier threads rather than restart it again while they are away from the PC.

Historical recurrence and app launches

The retained desktop trace contains successful desktop.startup spans, including app ready, at:

2026-10-19 22:36:55 UTC / 20 October 06:36:55 Hong Kong time.
2026-10-20 22:40:47 UTC / 21 October 06:40:47 Hong Kong time.

Preview timeouts recur after both launches: for example, on 20 October at 12:53 UTC and on 21 October at 00:55 UTC (the original report). Current desktop process start times also agree with the latter launch. This corroborates fresh desktop launches before recurrence. It is not a controlled test performed immediately after restarting, and does not establish exactly how long a restart restores automation. No additional restart was performed for this follow-up.

Explicit includeImage:false was already tried in earlier threads

On 2026-10-20 12:53:24.454–12:53:40.476 UTC, an earlier Codex thread made this actual call (tab identifier replaced):

{
  "toolName": "t3-code.preview_snapshot",
  "input": {"tabId": "TAB_A", "includeImage": false},
  "output": {
    "error": {
      "_tag": "PreviewAutomationTimeoutError",
      "operation": "snapshot",
      "failureCount": 1,
      "message": "Preview automation snapshot timed out after 15000ms."
    }
  }
}

That call followed a successful navigation to a local HTML design draft, with a title, loading:false and visible:false. An image-enabled snapshot had just failed as well. This extends the evidence beyond today's game-root playtest, but the draft is still private and is not a minimal public repro. Passing includeImage:false is verified; bypassing internal capture stages is not claimed.

A scan of retained direct preview tool calls marked failed, excluding assistant summaries and quoted copies, found 98 timeout calls across 29 threads in the window 17 October 00:00 UTC through 20 October 16:00 UTC (exclusive):

77 snapshot, 14 evaluate, 3 click, 2 navigate, 1 waitFor, and 1 open.
21 snapshot failures explicitly passed includeImage:false.
Eight of the timeout calls occurred on 20 October Hong Kong time, before today's original report.

These are counts of recorded calls, not independent bugs or proof of a shared cause. Historical release versions and renderer engines were not verified.

Earlier 660000ms open timeout

There is also a separate earlier occurrence on 18 October:

startedAt:   2026-10-18T13:14:50.043Z
completedAt: 2026-10-18T13:25:51.176Z
call: preview_open({tabId: TAB_B, open:true})
result: Error: Preview automation open timed out after 660000ms.

This followed repeated snapshot timeouts. It establishes recurrence of that error value, not that 660000ms is a hard-coded constant on main.

Supporting startup trace lines

These are actual retained desktop span entries. Only the private log-directory path and run identifier were removed from event attributes.

Sanitized desktop startup spans

{"type":"effect-span","name":"desktop.startup","traceId":"cf5d85284f2df39553ca4c97df4801cd","spanId":"c810a0d5f21508f4","parentSpanId":"c30170911abb8c8d","sampled":true,"kind":"internal","startTimeUnixNano":"1792449415220342200","endTimeUnixNano":"1792449419271679500","durationMs":4051.3373,"attributes":{},"events":[{"name":"runtime logging configured","timeUnixNano":"1792449418697104400","attributes":{"scope":"desktop","component":"desktop-startup","effect.fiberId":4,"effect.logLevel":"INFO"}},{"name":"app ready","timeUnixNano":"1792449418718170900","attributes":{"scope":"desktop","component":"desktop-startup","effect.fiberId":4,"effect.logLevel":"INFO"}}],"links":[],"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"desktop.startup","traceId":"c3eb5a455c101bb22dd61dffab304e17","spanId":"7d452690cbfc21a6","parentSpanId":"fdcbacb7a680d373","sampled":true,"kind":"internal","startTimeUnixNano":"1792536047966330500","endTimeUnixNano":"1792536051516589100","durationMs":3550.2586,"attributes":{},"events":[{"name":"runtime logging configured","timeUnixNano":"1792536051057820000","attributes":{"scope":"desktop","component":"desktop-startup","effect.fiberId":4,"effect.logLevel":"INFO"}},{"name":"app ready","timeUnixNano":"1792536051072366000","attributes":{"scope":"desktop","component":"desktop-startup","effect.fiberId":4,"effect.logLevel":"INFO"}}],"links":[],"exit":{"_tag":"Success"}}

Still outstanding

A minimal public-page reproduction and a test with confirmed visible:true remain outstanding. Older attempts to request visibility are not treated as successful visible-tab tests. The original report's snapshot/evaluate/open timings were extracted from the server traces before rotation; the current retained server files now start at 2026-10-21 01:11:41 UTC, after those calls. Full raw server entries for those earlier calls can no longer be recovered from the currently retained files. The historical input/output evidence above remains in durable tool history.

No settings reset, save deletion, or new app restart was performed.

Completed the requested small-page and confirmed-visible checks at 2026-10-21 03:07–03:09 UTC / 11:07–11:09 Hong Kong time. The timeout did not reproduce in this run. No T3 restart, update, settings reset, or game-save change was performed.

Public page, confirmed visible

Opened a fresh default-profile tab with:

preview_open({
  url: "https://example.com/",
  profileId: "default",
  open: true,
  reuseExistingTab: false
})

The initial open response reported visible:false, but a later explicit preview_status({tabId}) confirmed visible:true before inspection. Page evaluation independently returned document.visibilityState:"visible", document.hidden:false, and document.readyState:"complete".

Evaluation passed in 78 ms.
preview_snapshot({tabId, includeImage:false}) passed in 201 ms.
preview_snapshot({tabId, includeImage:true, save:true}) passed in 164 ms and saved a PNG.

These are agent-measured round-trip times. The matching server spans are included below.

Minimal local page

Served the HTML below from an isolated temporary loopback server, with no game code, assets, audio or external dependencies.

On the same visible tab, navigation and status reported visible:true; the page also reported visibilityState:"visible" / hidden:false.

Evaluation passed in 65 ms.
Explicit includeImage:false snapshot passed in 141 ms.

Opened a second fresh default-profile tab on the identical local URL with open:false:

T3 status confirmed visible:false for that second tab.
The document nevertheless reported visibilityState:"visible" / hidden:false.
Evaluation passed in 38 ms; no-image snapshot passed in 88 ms.
A tool-driven button click passed, and evaluation confirmed the counter changed from 0 to 1.
An image-enabled saved snapshot also passed in 86 ms.

Thus the T3 tab-visibility flag and document visibility were different in the background control. This did not trigger the historical failure here.

Complete minimal local page

<!doctype html>
<html lang="en">
<meta charset="utf-8">
<title>T3 preview minimal probe</title>
<h1>T3 preview minimal probe</h1>
<p id="state">ready</p>
<button id="increment" type="button">Increment</button>
<output id="count">0</output>
<script>
let clicks = 0;
document.querySelector('#increment').addEventListener('click', () => {
  document.querySelector('#count').textContent = String(++clicks);
});
</script>
</html>

Save as probe.html and serve its directory with python -m http.server 8000 --bind 127.0.0.1; the actual run used an automatically allocated loopback port.

Runtime difference / limits

All evaluated tabs in this run reported:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36

The original failing tab reported Electron/44.4.5 Chrome/152.0.7977.130, as documented above. The new passing user agent lacks the Electron identifier and reports Chrome 154. This is a runtime-identification difference, not a controlled retest of the original renderer, and does not establish that the original problem is fixed or that GA1 caused it.

Only the default profile was tested in this new run. The private game was not loaded, and the 11-minute same-tab reopen path was not repeated. No failing minimal public/local reproduction was obtained. Both test tabs were closed and the temporary server stopped afterward; existing tabs and running game tests were preserved.

Fresh raw server trace entries

Captured before rotation. Only the evaluated tab identifier is replaced with TAB_VISIBLE. In order: public-page open, public-page evaluation, public-page no-image snapshot, and background local-page no-image snapshot. The snapshot spans omit tool/parameter attributes in the raw log; correlation uses their enclosing recorded call times.

Raw MCP server spans for this passing run

{"type":"effect-span","name":"McpServer.@effect/mcp/2025-06-18/tools/call","traceId":"d21a9281f07c3edbdeb9a3dec05aa4a2","spanId":"0b991ce73a455623","parentSpanId":"72a1b36761725944","sampled":true,"kind":"server","startTimeUnixNano":"1792552063298308100","endTimeUnixNano":"1792552073990556400","durationMs":10692.2483,"attributes":{"rpc.system.name":"effect_rpc","rpc.method":"@effect/mcp/2025-06-18/tools/call","tool":"preview_open","parameters":{"url":"https://example.com/","profileId":"default","open":true,"reuseExistingTab":false}},"events":[],"links":[],"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"McpServer.@effect/mcp/2025-06-18/tools/call","traceId":"47ca726f3c76f59f6bdd69dadfea204f","spanId":"8ec730b8ae2c2873","parentSpanId":"468901778ddf4e2f","sampled":true,"kind":"server","startTimeUnixNano":"1792552096485232100","endTimeUnixNano":"1792552096527308600","durationMs":42.0765,"attributes":{"rpc.system.name":"effect_rpc","rpc.method":"@effect/mcp/2025-06-18/tools/call","tool":"preview_evaluate","parameters":{"tabId":"TAB_VISIBLE","expression":"({title:document.title,ready:document.readyState,visibility:document.visibilityState,hidden:document.hidden,ua:navigator.userAgent,heading:document.querySelector('h1')?.textContent})"}},"events":[],"links":[],"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"McpServer.@effect/mcp/2025-06-18/tools/call","traceId":"7670be638de4246ec94c37217279fd79","spanId":"0b70dbb3bae70a65","parentSpanId":"398fb5ada42254ac","sampled":true,"kind":"server","startTimeUnixNano":"1792552096563199100","endTimeUnixNano":"1792552096726470900","durationMs":163.2718,"attributes":{"rpc.system.name":"effect_rpc","rpc.method":"@effect/mcp/2025-06-18/tools/call"},"events":[],"links":[],"exit":{"_tag":"Success"}}
{"type":"effect-span","name":"McpServer.@effect/mcp/2025-06-18/tools/call","traceId":"7bdd7d43a204a633c0a87be404559729","spanId":"e8a00b784130e402","parentSpanId":"49a29949210b70d5","sampled":true,"kind":"server","startTimeUnixNano":"1792552171436006000","endTimeUnixNano":"1792552171499298400","durationMs":63.2924,"attributes":{"rpc.system.name":"effect_rpc","rpc.method":"@effect/mcp/2025-06-18/tools/call"},"events":[],"links":[],"exit":{"_tag":"Success"}}

I’ve now updated to T3 Code v0.1.1, but haven’t yet confirmed whether this behavior persists. The figures below are from before that update, not v0.1.1 test results.

I analysed retained preview-tool history from 17 October 00:00 UTC through 21 October 03:30 UTC. Among 506 snapshot attempts, 84 returned the exact 15000ms timeout.

The strongest pattern is repeated failure on the same tab:

38/49 quick snapshot retries after a failed snapshot timed out again (77.6%). After a successful snapshot, only 2/254 nearby follow-up snapshots timed out (0.8%). “Quick” means within 120 seconds, with no intervening successful open/navigation. The trend also holds when restricted to explicit tab IDs: 19/25 timed out again.
All 84 timeouts had a preceding T3 status sample showing visible:false within five minutes. However, 371 successful snapshots also had that flag, so it is not a sufficient explanation. This is the preview metadata flag, not a measurement of document visibility at the instant of failure.
The last-observed URLs associated 73/84 timeouts with local design or overview/map/gallery pages. The failures extend beyond the main application.

This appears consistent with the stuck-tab symptoms in #16567. My working hypothesis is a capture/inspection operation stalling and leaving subsequent tab actions blocked, but the history does not establish which internal step stalls.

These are retrospective attempt counts, including retries, rather than independent incidents or a controlled causal experiment. Browser versions were sparsely sampled, so the earlier Chrome 152/154 difference remains inconclusive.

I see that v0.1.1 includes #20446, adding a 10-second snapshot limit. Whether that resolves the earlier repeated-failure behavior remains unverified on my machine. I still do not have a minimal public page that reproduces the failure.

I’ll continue observing normal use on v0.1.1 to see whether the timeouts or stuck-tab behavior recur.

Note

🤖 Claude Opus 5.5 responding on behalf of Theo

Thanks for the report. One part of this is fixed on main in #20446. Please test on the nightly built from main on 2026-10-21, or on the next stable release. One part is still open: inspection and evaluation can still stall, and reopening a preferred tab can still wait up to 660 seconds. If that part still matters to you, please open a new issue for that part only.

Navigation Menu

Repository navigation

[Bug]: Windows 0.1.0 preview snapshots time out on loaded local page; same-tab reopen blocks for 11 minutes #22594

Before submitting

Area

Summary

Steps to reproduce / recorded sequence

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Investigation limits and workaround

References

Historical recurrence and app launches

Explicit includeImage:false was already tried in earlier threads

Earlier 660000ms open timeout

Supporting startup trace lines

Still outstanding

Public page, confirmed visible

Minimal local page

Runtime difference / limits

Fresh raw server trace entries

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: Windows 0.1.0 preview snapshots time out on loaded local page; same-tab reopen blocks for 11 minutes #22594

Description

Before submitting

Area

Summary

Steps to reproduce / recorded sequence

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Investigation limits and workaround

References

Activity

juliusmarminge commented on Oct 21, 2026

achose369 commented on Oct 21, 2026

Historical recurrence and app launches

Explicit includeImage:false was already tried in earlier threads

Earlier 660000ms open timeout

Supporting startup trace lines

Still outstanding

achose369 commented on Oct 21, 2026

Public page, confirmed visible

Minimal local page

Runtime difference / limits

Fresh raw server trace entries

achose369 commented on Oct 21, 2026

t3dotgg commented on Oct 21, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions