[Bug]: preview_press does not reliably target the preview page

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Start T3 Code Desktop.
Open a Codex-backed thread with the T3 preview MCP tools available.
Open any page in the browser preview.

Install a page-level keydown listener:

(() => {
  window.__t3KeyEvents = [];
  window.addEventListener(
    "keydown",
    (event) => {
      window.__t3KeyEvents.push({
        key: event.key,
        code: event.code,
        target: event.target && event.target.tagName,
        active: document.activeElement && document.activeElement.tagName,
        time: Date.now()
      });
    },
    true
  );
  return {
    active: document.activeElement && document.activeElement.tagName,
    events: window.__t3KeyEvents
  };
})()

Confirm document.activeElement is BODY.
Call preview_press before clicking inside the page:
```
{ "key": "b" }
```
Read window.__t3KeyEvents.
Click inside the preview page body with preview_click.
Clear the log and call preview_press again:
```
{ "key": "c" }
```
Clear the log and call preview_press with Escape three times.
In a separate hidden or degraded tab, call preview_press with Tab, then call a simple preview_evaluate.

Expected behavior

preview_press should target the selected preview page consistently when a tabId is provided.

If the preview page is not focusable or the tab cannot receive keyboard events, the tool should return a clear failure. It should not return null while no key event reaches the page.

Keyboard events should not go to the T3 host prompt when the agent is trying to target the preview page.

Actual behavior

Before a real click inside the page, preview_press("b") returned null, but the page captured no key event:

{
  "active": "BODY",
  "events": []
}

After clicking the page body, preview_press("c") returned null and the page captured the event:

{
  "active": "BODY",
  "events": [
    {
      "active": "BODY",
      "code": "KeyC",
      "key": "c",
      "target": "BODY"
    }
  ]
}

After focus was established, three Escape presses all returned null, but only two page-side keydown events were captured.

In an earlier run, a printable key was not captured by the page and the human operator observed that the character appeared in the T3 prompt input instead.

On a previously degraded invisible tab, preview_press("Tab") timed out after 15 seconds, and a simple preview_evaluate immediately afterward also timed out.

Impact

Major degradation or frequent failure

Version or commit

T3 Code desktop 0.0.28-1 via t3code-bin AUR package.

Environment

Arch Linux x86_64, kernel 7.0.13-arch1-1, T3 Code desktop AppImage package via t3code-bin, Codex provider.

Logs or stack traces

Representative timeout after pressing in a degraded invisible tab:

PreviewAutomationTimeoutError: Preview automation press timed out after 15000ms.
PreviewAutomationTimeoutError: Preview automation evaluate timed out after 15000ms.

Screenshots, recordings, or supporting files

No screenshot included. Page-side key event logs are the relevant evidence. A recording could help demonstrate the host-prompt mutation, but the agent cannot inspect that host input directly.

Workaround

Before using preview_press, click inside the preview page and verify delivery with a page-side listener or an observable page effect. Avoid keyboard workflows in hidden or already-degraded tabs. Prefer preview_type for text input and preview_evaluate for state changes that are not specifically testing keyboard behavior.

Are you by chance using the t3 serve command to have a remote instance?

I was connected from windows and my macbook to my linux dev box at the same time and noticed it was having a hard time with the preview and realized the preview was getting launched on my macbook even though i was prompting/interacting from my windows machine.

Additionally some of the commands like snapshot, click, and other tools fail with a "tab reports hidden" unless you actively have that browser tab open.

Sorry for the delayed response, but no, I am not using remote instances here. This is all local here

Summary

Keystrokes issued through T3 Code's preview_press browser-automation tool were explicitly targeted at one preview tab, but some of those keystrokes appeared in an unrelated input field that the user was actively editing.

This appears to violate the isolation boundary between an agent-controlled browser preview and other user-controlled surfaces. Depending on which surfaces can receive the leaked events, a malicious agent might be able to inject text or commands into T3 Code controls, terminals, authenticated forms, or conversations with other agents.

I have not confirmed command execution, cross-agent control, or a JavaScript sandbox escape. Those are potential impacts that should be investigated.

Confirmed observation

At 2026-08-11T06:12:19.572Z, an agent ran the following tool-orchestration code:

for (const key of "thisisunsafe") {
  await tools.mcp__t3_code__preview_press({
    tabId: "tab_5",
    key,
  });
}

The intention was to send Chrome's interstitial bypass sequence exclusively to preview tab tab_5.

While this happened, the user was working in an unrelated input field and saw the characters:

s...a...f...e...

appear one at a time over approximately two seconds. This exactly matches the final four characters of the automation sequence.

No Enter key, modifiers, click, or submit action was sent during this event.

Expected behavior

preview_press({tabId: "tab_5", ...}) should deliver input only to the browser target identified by tab_5.

If strict delivery cannot be guaranteed, the tool should fail closed without generating any keyboard event.

It should never deliver input to:

another preview tab;
a T3 Code host-interface input;
an editor or terminal;
an input associated with another worktree or agent session;
another application or globally focused operating-system control.

Actual behavior

At least four character events intended for tab_5 reached an unrelated user-focused input.

The gradual character-by-character appearance suggests that the individual preview_press events themselves were misrouted, rather than text being copied or pasted by the user.

Security impact

This may create a confused-deputy or capability-boundary vulnerability. An agent authorized only to automate a browser preview could potentially act with the user's authority in another focused surface.

Potential impacts requiring investigation include:

injecting commands into a focused terminal and submitting them with Enter;
modifying or submitting authenticated forms;
typing into T3 Code control-plane inputs;
sending instructions or messages to unrelated agent sessions;
triggering keyboard shortcuts with modifier keys;
interacting with another worktree, window, or browser tab;
bypassing permissions that assume preview automation is tab-scoped.

User focus appears to be a precondition in this observation, but that does not make the behavior safe because agents can issue individual keys, Enter, and modifier combinations.

Scope and confirmed limits

The observed event proves cross-surface character injection.

It does not currently prove:

arbitrary command execution;
access to another agent's environment;
use of collaboration or agent-management APIs;
a JavaScript page-sandbox escape;
persistence outside the affected input;
successful form submission.

An audit of the affected session found no calls to agent spawning, agent messaging, follow-up, or interruption tools. The accidental sequence contained no Enter key, so it did not execute or submit the text it injected.

Suggested reproduction

Use only disposable inputs and environments for this test.

Open a T3 Code browser preview and record its tabId.
Focus a harmless canary input outside that preview.
Invoke preview_press repeatedly with the preview's explicit tabId.
Check whether any character or input event reaches the canary field.
Repeat with:
- the target preview visible and hidden;
- multiple preview tabs;
- multiple worktrees or agent sessions;
- host UI, editor, and terminal canary fields;
- preview_type, Enter, and modifier combinations;
- focus changing during a sequence.

Do not test Enter or shortcuts against a real terminal or authenticated form.

Suggested remediation

Deliver keyboard events through a CDP or equivalent session bound to the exact target tab and frame.
Do not use operating-system-level or globally focused keyboard synthesis for preview tools.
Assert the target browser context, tab, frame, and web contents before every event.
Fail closed if the requested target is unavailable or cannot be uniquely resolved.
Audit preview_type, preview_click, paste, drag-and-drop, and other input-producing tools for the same routing problem.
Add isolation tests proving that non-target tabs and T3 Code host controls receive no input events.
Test concurrent user interaction and focus changes during multi-key sequences.
Include the resolved destination tab/frame in browser-action audit records.
Consider temporarily disabling preview_press modifier and Enter support until isolation is verified.

Environment

T3 Code Desktop v0.0.33 on macOS
Session originator: t3code_desktop
Codex CLI recorded by the session: 0.147.0
Date: 2026-08-11 UTC

Adding my encounter with this bug here rather than opening a new report. In my case, the agent attempting browser control was running from a remote t3 serve session. It was able to send keystrokes to the client machine's T3 desktop app.

I haven't investigated whether a clever agent could use this as a sandbox escape mechanism to control the client machine's agents (or agents within in the fleet of connected machines).

Possible security concern.

I think I just stumbled upon this issue as well. Regular keys were not passed, but as I was writing a prompt in a different thread, it got suddenly sent because a different agent (running on remote env) with web browser pressed Enter key.

I have encountered this as well while using the T3 browser preview. An Enter key event triggered by browser automation was intermittently routed to the T3 Code prompt composer instead of remaining scoped to the preview, causing the prompt I was writing to be submitted unexpectedly.

The affected prompt was outside the browser preview, and I did not manually press Enter at the time. The intermittent, cross-surface behavior matches the reports above and makes preview_press unsafe for Enter while another T3 Code input is focused.

We are also experiencing this on T3 Code 0.0.40 on macOS 27 with Codex. Key inputs intended for the T3 browser preview also reach the T3 Code interface, interfering with the prompt input.

@maria-rcks

#11354 appears to address the mistaken keystrokes part of this commit (thank you @maria-rcks!)

Unfortunately, preview_click still takes focus away from the composer.

Repro:
Keep typing in the composer.
Have the agent open a preview with preview_open(open: true).
Have the agent click a heading with preview_click.

Result: lose focus on the composer

Navigation Menu

Repository navigation

[Bug]: preview_press does not reliably target the preview page #3715

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Summary

Confirmed observation

Expected behavior

Actual behavior

Security impact

Scope and confirmed limits

Suggested reproduction

Suggested remediation

Environment

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: preview_press does not reliably target the preview page #3715

Description

Before submitting

Area

Steps to reproduce

Expected behavior

Actual behavior

Impact

Version or commit

Environment

Logs or stack traces

Screenshots, recordings, or supporting files

Workaround

Activity

Destreyf commented on Jul 15, 2026

gregbartell commented on Jul 22, 2026

rdbell commented on Aug 11, 2026

Summary

Confirmed observation

Expected behavior

Actual behavior

Security impact

Scope and confirmed limits

Suggested reproduction

Suggested remediation

Environment

rdbell commented on Aug 11, 2026

effektsvk commented on Aug 12, 2026

michidk commented on Sep 1, 2026

ViolentVotan commented on Sep 8, 2026

gregbartell commented on Sep 12, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions