[macOS] Warp no longer trigger notifications after updating claude code to 2.1.139 (agent view edition)

[liuxuan30]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Warp no longer trigger notifications after updating claude code to 2.1.139 (agent view edition)

Case 1: in agent list view(via claude agents), when needs input or error or complete, no warp notification(in app and desktop notification)

Case 2: use claude or claude --resume to enter the tradtional workflow, when a long task finish or needs user input, no notification(in app and desktop) as well.

I suspect the new claude code update breaks Warp's notification feature.

before updating claude code the notification feature works fine.

To reproduce

update claude code to 2.1.139

try case 1 and case 2.

Expected behavior

both case 1 and case 2 could trigger notification.

case 2 is the tradtional workflow, so case 2 is higher priority;

case 1 might be a new scenario, so warp might need a feature developement for the new introduced agent views.

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

26.3.1 (25D2128)

Shell Version

zsh 5.9 (arm64-apple-darwin25.0)

Current Warp version

v0.2026.05.06.15.42.stable_04

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

before updating claude code

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@liuxuan30

Here's what I found while triaging this issue:

This looks consistent with Warp not receiving the structured Claude Code notification/status events it uses for CLI-agent completion and needs-input notifications after the Claude Code update. We need the Claude Code Warp plugin state and a short reproduction capture to confirm whether the events stopped or changed shape.

I have a few follow-up questions before I can narrow this down:

1. Can you attach a short screen recording of one claude --resume run reaching completion or needing input while Warp is unfocused or on another tab/window?
2. After updating Claude Code, what does claude plugin list show for warp@claude-code-warp?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that macOS user reports that Warp no longer shows in-app or desktop notifications for Claude Code completion/attention states after updating Claude Code to 2.1.139..

Triage summary

This looks like a plausible Warp bug/regression in the Claude Code CLI-agent notification path on macOS, triggered after updating Claude Code to 2.1.139. The report covers both the new agent-list/agent-view notification surface and the traditional claude / claude --resume terminal workflow.

Current evidence

• Reporter is on macOS 26.3.1, zsh 5.9, Warp v0.2026.05.06.15.42.stable_04.
• Notifications previously worked before the Claude Code update, then stopped for completion, needs-input, and error states.
• Reporter says the behavior is Warp-only.
• No logs, video, or Claude plugin/version details were provided.

Code-path notes

• OSC 9/OSC 777 pluggable notifications are parsed in app/src/terminal/model/ansi/mod.rs and forwarded through TerminalModel::pluggable_notification in app/src/terminal/model/terminal_model.rs.
• Structured CLI-agent notifications are intercepted in app/src/terminal/view.rs when the OSC 777 title is warp://cli-agent; the raw JSON is suppressed and Warp relies on handle_cli_agent_notification plus CLIAgentSessionListener for subsequent status events.
• Claude/OpenCode/Gemini-style events are parsed by app/src/terminal/cli_agent_sessions/event/mod.rs and event/v1.rs. Status transitions are produced in app/src/terminal/cli_agent_sessions/mod.rs for stop, permission_request, and question_asked.
• Desktop notifications for CLI agents are sent from TerminalView::handle_cli_agent_session_event only after a non-InProgress status and only when the user is navigated away. In-app HOA notifications are populated by AgentNotificationsModel::handle_cli_agent_session_event.
• General long-running command notifications in TerminalView::maybe_send_long_running_command_notification intentionally skip blocks that were part of agent interaction, so Claude sessions can lose the fallback notification path if the structured plugin events stop arriving.
• The Claude plugin manager in app/src/terminal/cli_agent_sessions/plugin_manager/claude.rs expects the warp@claude-code-warp plugin and has install/update flows for that plugin.

Duplicate check

I fetched and compared all open non-PR issues. Related issues include #10549 (OpenCode/tmux notifications), #10187 (Windows CLI-agent notifications), #9052 (OSC 99 support), #8907 (Linux notifications), and #8851 (badge notifications), but fewer than two match this macOS + Claude Code 2.1.139 + missing completion/attention notifications scenario closely enough to mark this as a duplicate.

Suggested next step

Ask the reporter for the Claude Code Warp plugin state and a short reproduction capture. If the plugin is present and current, the next investigation should verify whether Claude Code 2.1.139 changed plugin loading, event names, event schema, or OSC emission behavior for the agent-view/traditional modes.

Question reasoning

1. Can you attach a short screen recording of one claude --resume run reaching completion or needing input while Warp is unfocused or on another tab/window? — A recording would verify the exact focus/navigation state and whether neither desktop notifications nor in-app agent notifications appear for the traditional flow.
2. After updating Claude Code, what does claude plugin list show for warp@claude-code-warp? — Warp's Claude CLI-agent notification path depends on the Claude Code Warp plugin emitting structured status events, so the installed plugin/version state is needed to confirm the likely failure path.

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

Powered by Oz

[liuxuan30]

1.Can you attach a short screen recording of one claude --resume

I cannot record video. I tested it intentionally to switch to a chrome web page during claude running review tasks. Warp is behind chrome app.

again, the notification works fine before I update claude code. I just realize I didn't get any notification when claude finishes then I realize probably this is a new issue.

2.After updating Claude Code, what does claude plugin list show for warp@claude-code-warp?
claude plugin list:

  ❯ warp@claude-code-warp
    Version: 2.0.0
    Scope: user
    Status: ✔ enabled

[oz-for-oss]

@liuxuan30

Here's what I found while triaging this issue:

Thanks for confirming warp@claude-code-warp is enabled at version 2.0.0. Warp's current integration relies on Claude Code plugin hook events; claude agents appears to be a newer Claude Code surface that may need additional support, while claude/claude --resume should still notify if those hooks are firing correctly.

I have a few follow-up questions before I can narrow this down:

1. In the same Warp tab where notifications fail, can you run jq --version; echo ${WARP_CLI_AGENT_PROTOCOL_VERSION:-unset} and paste the output?
2. Inside the failing claude --resume session, does /hooks show the Warp plugin hooks registered for SessionStart, Stop, and Notification?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude Code notifications in Warp likely stopped because Warp is no longer receiving or successfully parsing the Claude Code plugin's structured hook notifications after the reporter upgraded to Claude Code 2.1.139..

Triage summary

This looks like a Warp/Claude Code integration bug, but the actionable failure point is still ambiguous. Warp's client-side path expects the warp@claude-code-warp plugin to emit structured OSC 777 notifications with the warp://cli-agent sentinel; Warp parses those into CLIAgentSessionsModel status changes and then sends in-app mailbox plus desktop notifications when the status becomes blocked or complete.

The reporter confirmed the plugin is installed and enabled at version 2.0.0, which matches the current minimum in app/src/terminal/cli_agent_sessions/plugin_manager/claude.rs. The remaining uncertainty is whether Claude Code 2.1.139 still runs the plugin hooks and emits compatible payloads in both reported paths. The claude agents list view may be a newer Claude Code surface that is not covered by the current plugin hooks, while claude/claude --resume should still be covered if SessionStart, Stop, and Notification hooks are registered and working.

Relevant local code paths checked:

• app/src/terminal/model/ansi/mod.rs parses OSC 9 and OSC 777 pluggable notifications.
• app/src/terminal/model/terminal_model.rs emits Event::PluggableNotification when the feature is enabled.
• app/src/terminal/view.rs suppresses raw structured CLI-agent notifications and routes them through handle_cli_agent_notification, then sends desktop notifications only after CLI-agent status changes.
• app/src/terminal/cli_agent_sessions/listener/mod.rs subscribes to parsed PluggableNotification events and updates CLIAgentSessionsModel.
• app/src/terminal/cli_agent_sessions/event/v1.rs only accepts the current v1 event shape and known event names.
• app/src/ai/agent_management/agent_management_model.rs adds in-app notification mailbox entries for CLI-agent success/blocked states.

Duplicate search: no two open issues appear to match this exact macOS + Claude Code 2.1.139 + Warp plugin notification regression. Related notification issues exist, but they cover different agents/platforms or broader notification requests.

Question reasoning

1. In the same Warp tab where notifications fail, can you run jq --version; echo ${WARP_CLI_AGENT_PROTOCOL_VERSION:-unset} and paste the output? — The Claude Code Warp plugin needs jq to build structured payloads and uses WARP_CLI_AGENT_PROTOCOL_VERSION to decide whether to emit them; these values are session-specific and cannot be inferred from the issue.
2. Inside the failing claude --resume session, does /hooks show the Warp plugin hooks registered for SessionStart, Stop, and Notification? — The plugin list confirms installation, but hook registration can still fail or be demoted by Claude Code; this determines whether Warp should be receiving the events that drive notifications.

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

Powered by Oz

[liuxuan30]

Regarding "while claude/claude --resume should still notify if those hooks are firing correctly.":
No, it simply not work. No notification at all with normal claude --resume

In the same Warp tab where notifications fail, can you run jq --version; echo ${WARP_CLI_AGENT_PROTOCOL_VERSION:-unset} and paste the output?

the output:

jq --version; echo ${WARP_CLI_AGENT_PROTOCOL_VERSION:-unset}
jq-1.7.1-apple
1

Inside the failing claude --resume session, does /hooks show the Warp plugin hooks registered for SessionStart, Stop, and Notification?

here's the output:

Hooks
  7 hooks configured

 6.  Notification (1)   
 9.  SessionStart (2) 
 10. Stop (1) 

Notification

  Notification - Matcher: idle_prompt
  Input to command is JSON with notification message and type.
  Exit code 0 - stdout/stderr not shown
  Other exit codes - show stderr to user only

  ❯ 1. [command] ${CLAUDE_PLUGIN_ROOT}/scripts/on-notification.sh  Plugin Hooks (warp@claude-code-warp)

SessionStart:

  SessionStart - Matcher: startup|resume
  Input to command is JSON with session start source.
  Exit code 0 - stdout shown to Claude
  Blocking errors are ignored
  Other exit codes - show stderr to user only

  ❯ 1. [command] ${CLAUDE_PLUGIN_ROOT}/scripts/on-session-start.sh  Plugin Hooks (warp@claude-code-warp)

Stop:

  Stop
  Exit code 0 - stdout/stderr not shown
  Exit code 2 - show stderr to model and continue conversation
  Other exit codes - show stderr to user only

  ❯ 1. [command] ${CLAUDE_PLUGIN_ROOT}/scripts/on-stop.sh  Plugin Hooks (warp@claude-code-warp)

[oz-for-oss]

@liuxuan30

Here's what I found while triaging this issue:

The plugin is enabled and the core Stop/Notification hooks are present, but your /hooks output is missing several hooks that the current Warp Claude plugin defines. Also, Claude's idle_prompt path currently does not create a Warp needs-attention notification, so that part looks like a Warp-side gap; the missing completion notification still needs one environment check.

I have a few follow-up questions before I can narrow this down:

1. In the same failing Warp tab, can you run echo ${WARP_CLIENT_VERSION:-unset}; echo ${TERM_PROGRAM:-unset} and paste the output?
2. After running /reload-plugins in Claude Code, does /hooks still show only Notification, SessionStart, and Stop, or does it also show PermissionRequest, UserPromptSubmit, and PostToolUse?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that claude Code 2.1.139 on macOS appears to stop producing Warp CLI-agent notifications despite the Warp plugin being enabled and core hooks registered..

Triage

This looks like a real Warp/Claude Code integration bug rather than a generic macOS notification-permission issue. The reporter confirmed the Warp Claude plugin is enabled (warp@claude-code-warp v2.0.0), jq is available, WARP_CLI_AGENT_PROTOCOL_VERSION=1, and /hooks includes the key SessionStart, Stop, and Notification hooks.

Most likely path:

• Warp consumes Claude Code plugin notifications through structured OSC 777 events with the warp://cli-agent sentinel.
• Stop should become a CLI-agent Success status and then create both mailbox/toast state and, when the tab/window is not active, a desktop notification.
• Notification with matcher idle_prompt currently parses as IdlePrompt; the client intentionally ignores IdlePrompt for status changes, so idle prompts do not currently create a needs-attention notification through this path.
• The current upstream plugin also defines PermissionRequest, UserPromptSubmit, and PostToolUse hooks, but the reporter's /hooks output only shows Notification, SessionStart, and Stop, which may indicate an incomplete/stale plugin registration or a Claude Code hook-loading difference after 2.1.139.

Relevant code paths:

• app/src/terminal/cli_agent_sessions/plugin_manager/claude.rs manages the warp@claude-code-warp plugin and minimum version.
• app/src/terminal/cli_agent_sessions/event/mod.rs and app/src/terminal/cli_agent_sessions/event/v1.rs parse structured CLI-agent notification events.
• app/src/terminal/cli_agent_sessions/mod.rs maps Stop, PermissionRequest, and QuestionAsked into session status changes while ignoring IdlePrompt.
• app/src/terminal/view.rs registers CLI-agent listeners and sends CLI-agent desktop notifications when the terminal is navigated away.
• app/src/ai/agent_management/agent_management_model.rs creates in-app notification mailbox items for CLI-agent status changes.

No duplicate cluster was found. The closest open issue, #10187, is Windows notification-app registration specific. Recent closed #10147 is WSL-specific and reported desktop notifications still appearing, so it does not match this macOS no-notification failure.

Question reasoning

1. In the same failing Warp tab, can you run echo ${WARP_CLIENT_VERSION:-unset}; echo ${TERM_PROGRAM:-unset} and paste the output? — The plugin's structured notification path requires WARP_CLIENT_VERSION, and its legacy fallback depends on TERM_PROGRAM; WARP_CLI_AGENT_PROTOCOL_VERSION=1 alone does not prove the script is emitting the structured OSC event.
2. After running /reload-plugins in Claude Code, does /hooks still show only Notification, SessionStart, and Stop, or does it also show PermissionRequest, UserPromptSubmit, and PostToolUse? — The current Warp Claude plugin defines additional hooks beyond the ones shown in the report, so this distinguishes an incomplete/stale plugin registration from a client-side event handling bug.

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

Powered by Oz

[liuxuan30]

In the same failing Warp tab, can you run echo ${WARP_CLIENT_VERSION:-unset}; echo ${TERM_PROGRAM:-unset} and paste the output?

Output:

echo ${WARP_CLIENT_VERSION:-unset}; echo ${TERM_PROGRAM:-unset}
v0.2026.05.06.15.42.stable_04
WarpTerminal

After running /reload-plugins in Claude Code, does /hooks still show only Notification, SessionStart, and Stop, or does it also show PermissionRequest, UserPromptSubmit, and PostToolUse?

it has total 28 hook items, including PermissionRequest, UserPromptSubmit, and PostToolUse.

I only mentioned what you asked before, the rest of them I didn't intend to mention. So to your newly added PermissionRequest, UserPromptSubmit, and PostToolUse, they all have warp scripts listed.

[oz-for-oss]

@liuxuan30

Here's what I found while triaging this issue:

Thanks for confirming the Warp version, terminal env, and reloaded Claude hooks. This no longer looks blocked on missing plugin registration; the next step is engineering investigation into which Claude Code 2.1.139 hook events actually reach Warp for claude --resume and the new claude agents view.

Maintainer details

I concluded that claude Code 2.1.139 on macOS appears to stop producing Warp CLI-agent notifications even though the Warp Claude plugin is installed, enabled, and exposing the expected structured hook set..

Triage summary

The reporter is on macOS with Warp v0.2026.05.06.15.42.stable_04, zsh 5.9, Claude Code 2.1.139, and warp@claude-code-warp plugin version 2.0.0. They report no in-app or desktop notifications from both the new claude agents list view and the traditional claude / claude --resume flow after updating Claude Code.

Follow-up answers confirmed the failing Warp tab has WARP_CLIENT_VERSION=v0.2026.05.06.15.42.stable_04, TERM_PROGRAM=WarpTerminal, WARP_CLI_AGENT_PROTOCOL_VERSION=1, and jq available. /hooks initially showed the requested SessionStart/Stop/Notification hooks, and after /reload-plugins it shows the broader Warp hook set including PermissionRequest, UserPromptSubmit, and PostToolUse. That makes this unlikely to be a simple missing-plugin, missing-jq, or stale-hook-registration case.

Likely technical area

Warp's Claude CLI notifications depend on structured OSC 777 events with the warp://cli-agent sentinel. TerminalView::handle_cli_agent_notification parses those events and registers a CLI-agent listener, CLIAgentSessionsModel::apply_event converts status-changing events into Success or Blocked, and AgentNotificationsModel / TerminalView::handle_cli_agent_sessions_event produce in-app and desktop notifications from those status changes.

The important distinction is that stop, permission_request, and question_asked can trigger notifications, while idle_prompt is currently ignored so it does not override a successful stop state. If Claude Code 2.1.139 now emits only Notification/idle-prompt-style events for the affected states, changes its Stop/PermissionRequest hook behavior, or isolates the new claude agents view from the PTY where Warp listens, Warp would see no status transition and therefore create no notification. The traditional claude --resume case should still work if Stop/PermissionRequest hooks emit parseable structured OSC payloads, so that path is the highest-priority regression to verify.

Duplicate check

I enumerated open issues and reviewed notification-adjacent candidates. #10187 is a Windows app-registration/native notification problem, #8907 is a Linux desktop-notification problem, and the recent closed #10147 was WSL-specific structured/legacy notification behavior. None match this macOS + Claude Code 2.1.139 hook-notification regression closely enough, and there are fewer than two likely duplicates, so this should remain a standalone issue.

Suggested next investigation

Reproduce on macOS with Claude Code 2.1.139 and plugin 2.0.0, then verify whether the hook scripts emit warp://cli-agent OSC 777 payloads for stop, permission_request, question_asked, and idle_prompt in both claude --resume and claude agents. If only idle_prompt or no structured event arrives, the fix likely belongs in the Claude plugin hook mapping or in Warp's handling for the new Claude agent-view workflow.

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

Powered by Oz