fix: prevent notifications leaking into other terminals

[kitlangton]

What happened

I launched Zed from a Warp shell, then ran OpenCode in Zed's integrated terminal.

Zed correctly identified itself with TERM_PROGRAM=zed, but it also inherited WARP_CLI_AGENT_PROTOCOL_VERSION=1 from Warp. The plugin checked only the inherited Warp variable, assumed the current terminal was Warp, and wrote a Warp-specific OSC 777 notification directly to /dev/tty.

Because the current terminal was actually Zed, the notification payload appeared as raw text over the OpenCode TUI. The output was especially large because the notification was for a patch permission and contained the escaped diff.

flowchart LR
    A[Warp launches Zed] --> B[Zed inherits Warp protocol variable]
    B --> C[OpenCode loads Warp plugin]
    C --> D[Plugin writes OSC 777 to /dev/tty]
    D --> E[Zed renders payload over OpenCode TUI]

Loading

How this fixes it

Before writing an OSC 777 notification, the plugin now checks whether the current terminal explicitly identifies itself as something other than Warp. If it does, the notification is skipped.

flowchart LR
    A[Notification ready] --> B{TERM_PROGRAM}
    B -->|WarpTerminal or unset| C[Send OSC 777]
    B -->|Another terminal, such as Zed| D[Skip notification]

Loading

The check stays at the /dev/tty output boundary, so no other plugin behavior changes. Leaving TERM_PROGRAM unset remains supported for Warp-managed SSH sessions.

Verification

• bun run test
• bun run typecheck
• bun run build

Regression coverage includes Zed with inherited Warp variables, a normal Warp terminal, and an SSH-style environment with no TERM_PROGRAM.

[arijitcodes]

Hi @kitlangton
Please add @harryalbert as a reviewer on your PR, it helps him to track on his side.
He is the maintainer.

Also, just a friendly suggestion, if possible, please mention the version and basic details on the descriptions, such as:
Operating System:
OpenCode Version:
opencode-warp Plugin Version:
Warp Version:

[harryalbert]

Thanks for submitting this @kitlangton! Overall seems reasonable.

Could you bump the version (see this PR for an example of where to bump)? I want to make this process more automated, but in the meantime we have to version bump manually so that we can actually release a new version once this is merged