Skip to content

[Bug]: Server-runtime side-panel browser can't copy to the local clipboard — no safe way to hand off show-once secrets #26600

Closed

Description

@ViperJuice

Before submitting

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

Related but different: #11874 (desktop in-app browser copy/paste, closed), #19647 (mobile paste, closed), and #25403 (fill a preview input from a secretRef, closed). That last one covers secrets going into a page. This issue is the other direction: getting a secret out of a server-runtime tab without it entering model context.

Area

apps/server (server-runtime preview browser), with desktop clipboard bridging

Environment

  • T3 Code desktop client connected to a remote environment on a Linux server host
  • The environment's preview / side-panel browser runs on the server (runtime: "server" tabs)
  • Server: t3 v0.1.4-nightly.20261028.3824

Steps to reproduce

  1. From the desktop client, open a server-runtime preview tab for a remote Linux environment.
  2. Sign in to a site that shows a secret only once. Example: create a GitHub fine-grained personal access token. GitHub shows the value one time.
  3. Select the value in the panel and copy it (keyboard shortcut or the site's own "copy" button).
  4. Try to paste it anywhere on the local client machine.

Expected behavior

Copying in the side-panel browser puts the text on the local client's clipboard, as in a normal browser. At minimum, there should be some safe way to move a value out of the panel.

Actual behavior

The copied text never reaches the local clipboard. Copy/paste doesn't bridge from the server-side browser to the client machine. A show-once secret shown in the panel is therefore stranded: the user can't paste it into a password manager, a terminal, or request_secret.

The agent's options are also poor:

  • Reading the value with preview_evaluate or preview_snapshot puts the secret into model context and the transcript.
  • request_secret needs the user to paste the value, and they can't.

Impact

Major degradation or frequent failure. Any flow that creates a show-once credential in the panel (API tokens, PATs, recovery codes, webhook secrets) ends with either a leaked secret or a wasted one that has to be regenerated.

Workaround

The agent started a one-shot HTTP listener on the server's loopback. It then ran page JS that opened http://127.0.0.1:<port>/?t=<value> in a new tab, so the listener wrote the value to a 0600 file without it entering model context. Afterwards the agent closed the tab and shredded the file.

Downsides:

  • It's a hack.
  • The value appears in a URL, so it lands in that browser profile's history.
  • It only works because the preview browser runs on the same host as the agent's shell.
  • The extra tab had to be found and closed by hand.

Related friction (secondary)

  • A tab the user opened in the desktop app's panel couldn't be automated by the agent. Only runtime: "server" tabs can.
  • An agent-opened server tab on the "default" profile didn't share the logged-in session from the user's desktop tab, so the user had to log in again in the agent's tab.

Suggestions

  1. Clipboard bridging between server-runtime preview tabs and the local client. At least copy from the panel to the local clipboard; paste in the other direction would also help.
  2. A first-class "capture to secret" path, the mirror of Fill a preview input from a secretRef (agent logins without the secret in model context) #25403. For example, a preview tool, or a user action in the panel ("Save selection as secret"), that takes the value of a selected element or text selection and stores it as a request_secret-style secretRef or a private file. The value would never be returned to the model.
  3. Docs (optional): say which tabs agents can automate (desktop-panel vs. server-runtime), and whether browser profiles and sessions are shared between desktop-panel tabs and server tabs.

🤖 Generated with Claude Code

Activity

  1. t3dotgg commented on Oct 31, 2026

    @t3dotgg
    Member

    Note

    🤖 Claude Opus 5.5 responding on behalf of Theo

    Closing: this is covered by #26633, which landed. Reopen if an important part is still missing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions