feat(cli): add browse clipboard commands

[optimusbuilder]

##why
The SDK exposes context.clipboard, but the browse CLI had no way to use it — users had to fall back to raw CDP.

##what changed
-Six driver commands: clipboard.read, write, paste, copy, cut, clear
-Matching oclif commands: browse clipboard read|write|paste|copy|cut|clear
-Wired through DriverSessionManager.browserContext() → context.clipboard (no core changes)
paste supports --shortcut Control+V|Meta+V|ControlOrMeta+V

• Unit tests for handler wiring + command registration

##test plan

pnpm exec vitest run tests/clipboard.test.ts tests/driver-commands.test.ts

Manual: write → read → paste on a focused input

---

Summary by cubic

Add clipboard support to the browse CLI with commands to read, write, paste, copy, cut, and clear. Enables agents and terminal users to use the SDK clipboard without raw CDP.

• New Features
  • Implemented driver handlers for clipboard.read|write|paste|copy|cut|clear, wired via DriverSessionManager.browserContext() to context.clipboard.
  • Exposed as oclif commands: browse clipboard read|write|paste|copy|cut|clear; paste supports --shortcut (Control+V, Meta+V, ControlOrMeta+V).
  • Added vitest tests for handler wiring and CLI registration.

^{Written for commit c372551. Summary will update on new commits.}

[changeset-bot]

🦋 Changeset detected

Latest commit: c372551

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 0 packages

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

This PR is from an external contributor and must be approved by a stagehand team member with write access before CI can run.
Approving the latest commit mirrors it into an internal PR owned by the approver.
If new commits are pushed later, the internal PR stays open but is marked stale until someone approves the latest external commit and refreshes it.

[cubic-dev-ai]

No issues found across 12 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

Architecture diagram

sequenceDiagram
    participant User as CLI User
    participant Oclif as oclif Command
    participant CLI as Driver Command CLI
    participant Handlers as Clipboard Handlers
    participant Manager as DriverSessionManager
    participant Context as BrowserContext
    participant Clipboard as Clipboard API

    Note over User,Clipboard: NEW: Browse Clipboard Commands

    User->>Oclif: browse clipboard read|write|paste|copy|cut|clear [--session] [args]
    Oclif->>Oclif: Parse flags/args

    alt clipboard.write
        Oclif->>CLI: runDriverCommandFromFlags("clipboard.write", {text})
    else clipboard.paste
        Oclif->>CLI: runDriverCommandFromFlags("clipboard.paste", {shortcut})
    else other commands
        Oclif->>CLI: runDriverCommandFromFlags("clipboard.<cmd>", {})
    end

    CLI->>Handlers: Dispatch to clipboard.<cmd> handler
    Handlers->>Manager: browserContext()
    Manager-->>Handlers: BrowserContext instance

    alt clipboard.read
        Handlers->>Clipboard: readText()
        Clipboard-->>Handlers: clipboard text
        Handlers-->>CLI: { text }
    else clipboard.write
        Handlers->>Clipboard: writeText(text)
        Clipboard-->>Handlers: void
        Handlers-->>CLI: { ok: true }
    else clipboard.paste
        Handlers->>Clipboard: paste({ shortcut } | undefined)
        Clipboard-->>Handlers: void
        Handlers-->>CLI: { ok: true }
    else clipboard.copy|cut|clear
        Handlers->>Clipboard: copy() | cut() | clear()
        Clipboard-->>Handlers: void
        Handlers-->>CLI: { ok: true }
    end

    CLI-->>Oclif: Result
    Oclif-->>User: Display result

Loading

_{Re-trigger cubic}

[shrey150]

is clipboard siloed by browser / tab like this?

[optimusbuilder]

it’s not tab-siloed.
browse clipboard * runs against the active page (for focus + permission grant), but the clipboard value is shared across tabs in that browser session.
so when you write in tab 0 and switch to tab 1, read returns the same value.
So --session here selects which browse daemon/browser session to target, not per-tab clipboard isolation.

[github-actions]

This PR was approved by @shrey150 and mirrored to #2241. All further discussion should happen on that PR.