Claude Code mailbox stays empty on WSL because plugin falls back to legacy OSC 777 notifications

[harryalbert]

Summary

On WSL, the Claude Code plugin emits the legacy OSC 777 notification format instead of the structured warp://cli-agent format, so per-task entries never appear in Warp's notification mailbox in the top-right. Toasts and OS-level (Windows Action Center) notifications still render, which makes this look like a partial / silent failure.

Problem

A Reddit user (Aoshi_) reports that on WSL, "Claude has completed a task" toasts show up and Windows Action Center receives notifications, but the mailbox dropdown in the top-right of Warp is always empty after Claude finishes a task. Reinstalling the plugin and updating both Warp and the plugin did not help. The same flow works on macOS/Linux/native-Windows, where mailbox entries appear as expected.

Original report: https://old.reddit.com/r/warpdotdev/comments/1snko27/

Expected behavior

After Claude Code completes a task in a WSL pane, an entry should appear in Warp's notification mailbox (top-right) describing the completed task, just like on macOS, native Linux, and native Windows. Clicking the entry should navigate to the originating terminal.

Actual behavior

• "Claude has completed a task" toast appears in Warp.
• Windows Action Center receives a notification.
• The notification mailbox in the top-right corner of Warp is always empty.

Reproduction steps or desired workflow

1. Run Warp on Windows with a WSL distro configured.
2. Install the Claude Code plugin (warpdotdev/claude-code-warp).
3. Open a WSL tab and start a Claude Code session.
4. Submit a prompt and let Claude finish it.
5. Observe that a toast appears, but the mailbox icon in the top-right shows no new items / opening the mailbox shows it empty.
6. Repeat with multiple sessions/prompts; mailbox stays empty.

Artifacts

None attached.

Warp version

Unknown (reporter said they "updated Warp and the plugin today" at the time of the Reddit thread, ~late April 2026, but did not specify a build).

Operating system

Warp on Windows host, with Claude Code running inside WSL (distro/version unspecified by reporter).

Possible source references

• app/src/terminal/local_tty/windows/environment.rs (lines 103-120 set WARP_CLIENT_VERSION and, when HOANotifications is enabled, WARP_CLI_AGENT_PROTOCOL_VERSION on the Windows-side env block; lines 155-180 build WSLENV for the WSL starter, which forwards only WARP_HONOR_PS1, WARP_USE_SSH_WRAPPER, WARP_SHELL_DEBUG_MODE, TERM_PROGRAM, WARP_IS_LOCAL_SHELL_SESSION, SSH_SOCKET_DIR, and optionally WARP_INITIAL_WORKING_DIR). Neither WARP_CLIENT_VERSION nor WARP_CLI_AGENT_PROTOCOL_VERSION is added to WSLENV, so they don't cross the Windows → WSL boundary and don't reach the Linux shell where the Claude plugin runs.
• claude-code-warp plugin: plugins/warp/scripts/should-use-structured.sh (the should_use_structured function returns 1 when either WARP_CLI_AGENT_PROTOCOL_VERSION or WARP_CLIENT_VERSION is empty, causing plugins/warp/scripts/on-stop.sh:9-12 to fall through to plugins/warp/scripts/legacy/on-stop.sh).
• plugins/warp/scripts/legacy/on-stop.sh:48 — legacy fallback emits OSC 777 with title Claude Code instead of warp://cli-agent.
• app/src/terminal/cli_agent_sessions/event/mod.rs:71-74 — parse_event early-returns None for any title that isn't the warp://cli-agent sentinel, so legacy-titled OSC 777 notifications are never lifted into CLIAgentEvents and never reach CLIAgentSessionsModel / AgentNotificationsModel (which back the mailbox UI in app/src/ai/agent_management/notifications/view.rs).
• For comparison, the macOS/Linux PTY env path (app/src/terminal/local_tty/unix.rs:276-288, 320-325) sets both env vars directly on the child process, which is why mailbox entries work there.
• Likely fix surface: extend the WSL WSLENV builder in windows/environment.rs to also forward WARP_CLIENT_VERSION and (gated on HOANotifications) WARP_CLI_AGENT_PROTOCOL_VERSION.

[oz-for-oss]

@harryalbert

Here's what I found while triaging this issue:

This appears limited to Claude Code running inside WSL on Windows. The toast path can still work while the mailbox stays empty because mailbox entries depend on structured CLI-agent events, and the WSL environment currently does not appear to receive the structured-notification capability vars.

Maintainer details

I concluded that claude Code notifications from WSL likely reach Warp only through the legacy toast path because the structured CLI-agent protocol env vars are not forwarded into WSL..

Triage

This looks like a Windows/WSL-specific bug in the structured CLI-agent notification path rather than a general Claude Code notification failure.

Evidence from the current codebase supports the proposed chain:

• app/src/terminal/local_tty/windows/environment.rs sets WARP_CLIENT_VERSION for Windows shells and sets WARP_CLI_AGENT_PROTOCOL_VERSION when HOANotifications is enabled, but the ShellStarter::Wsl WSLENV allowlist only forwards shell/terminal bootstrap vars such as WARP_HONOR_PS1, WARP_USE_SSH_WRAPPER, WARP_SHELL_DEBUG_MODE, TERM_PROGRAM, WARP_IS_LOCAL_SHELL_SESSION, and SSH_SOCKET_DIR.
• app/src/terminal/local_tty/unix.rs sets both WARP_CLIENT_VERSION and, when enabled, WARP_CLI_AGENT_PROTOCOL_VERSION directly on native Unix PTY children, which matches the report that native macOS/Linux works.
• The Claude Code plugin's plugins/warp/scripts/should-use-structured.sh requires both WARP_CLI_AGENT_PROTOCOL_VERSION and WARP_CLIENT_VERSION; if either is missing, plugins/warp/scripts/on-stop.sh executes the legacy stop hook.
• The legacy stop hook sends an OSC 777 notification with the normal Claude Code title, while app/src/terminal/cli_agent_sessions/event/mod.rs only parses structured CLI-agent events when the title is the warp://cli-agent sentinel.
• Parsed CLI-agent Stop events are what drive CLIAgentSessionsModel status changes and then AgentNotificationsModel mailbox entries, so legacy toasts can still render while the mailbox remains empty.

Likely fix surface: extend the WSL WSLENV construction in app/src/terminal/local_tty/windows/environment.rs to forward WARP_CLIENT_VERSION and, only when HOANotifications is enabled and the env var is set, WARP_CLI_AGENT_PROTOCOL_VERSION into WSL. This should be covered by a Windows/WSL environment-construction test if practical, or by a focused unit test around the WSL allowlist builder if that logic is extracted.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz