[BUG] Kitty notification path omits OSC 99 f= and n=, so notifications fall back to kitty's bundled logo and bypass the icon theme

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code (2.1.278)

What's Wrong?

On Linux with the kitty notification channel, Claude Code emits exactly three OSC 99 sequences, captured live from a 2.1.278 process:

ESC ] 99 ; i=3766:d=0:p=title ; Claude Code                      ESC \
ESC ] 99 ; i=3766:p=body      ; Claude is waiting for your input ESC \
ESC ] 99 ; i=3766:d=1:a=focus ;                                  ESC \

No f= (application name), no n= (icon name), no p=icon.

The kitty OSC 99 spec states that "well behaved applications should identify themselves to the terminal by means of two keys f which is the application name and t which is the notification type", that n= is the key for choosing an icon, and that "if no icon is specified, but the f key (application name) is specified, the terminal emulator should use the value of the f key to try to find a suitable icon." It also prefers an icon name over image data "so that users are presented with icons from their current icon theme, where possible."

With all three keys unset, kitty exhausts its resolution chain and falls back to its own bundled logo, handing the notification daemon an absolute file path rather than an icon name. Because a path is not a name, no icon-theme lookup happens at any layer — the user's icon theme cannot participate. Every notification titled "Claude Code" shows kitty's own logo.

Claude Code already establishes an application identity of exactly the form the spec asks for: it writes claude-code-url-handler.desktop on Linux and uses the bundle identifier com.anthropic.claude-code-url-handler on macOS. Neither is sent over OSC 99. That desktop entry also carries no Icon= key, so f= alone would not resolve an icon today.

What Should Happen?

The kitty notification path should send an application identity via f=, and preferably an icon name via n=, so the terminal can resolve the icon from the user's icon theme instead of falling back to its own logo.

Error Messages/Logs

method call interface=org.freedesktop.Notifications; member=Notify
   string "kitty"                              <- app_name
   uint32 0
   string "/usr/lib/kitty/logo/kitty.png"      <- app_icon (absolute path, not an icon name)
   string "Claude Code"                        <- summary
   string "Claude is waiting for your input"   <- body
   array [ string "default"  string " " ]
   array [ dict entry( string "urgency"  variant byte 1 ) ]
   int32 -1

urgency is the only hint; there is no image-data, image-path or desktop-entry hint.

Steps to Reproduce

1. Run Claude Code in kitty on Linux with any notification daemon running.
2. Start dbus-monitor --session "type='method_call',interface='org.freedesktop.Notifications',member='Notify'".
3. Let a turn end so the "Claude is waiting for your input" notification fires.
4. Read the captured Notify call: app_icon is kitty's bundled logo/kitty.png, and no image hint is present.

Is this a regression?

I don't know

Claude Code Version

2.1.278 (Claude Code)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other (kitty 0.48.2)

Additional Information

• Environment: CachyOS Linux, niri (Wayland), Noctalia 5.1.0 as the notification daemon, kitty 0.48.2, icon theme Noctalia-Folders → Papirus-Light → breeze, hicolor.
• Verified identically on 2.1.270 and 2.1.278; the OSC 99 emission is byte-for-byte the same on both. Eight Notify calls captured across four independent kitty windows, all identical.
• The theme is bypassed rather than incomplete: resolving the plain name kitty against the active theme yields Papirus-Light/48x48/categories/kitty.svg, which is never used because a path is sent instead of a name.
• There is no user-side configuration for this on either side. Claude Code documents only preferredNotifChannel, inputNeededNotifEnabled and agentPushNotifEnabled; kitty exposes only filter_notification and notify_on_cmd_finish. The only workaround is a notifications.py handler script in kitty's config directory.
• Related but distinct, all closed: #17912 (empty app_name on the PyCharm plugin path), #41511 (macOS notifications attributed to Script Editor), #40165 (OSC 99 support assumed rather than queried).

No source file or test is named in the report. Start by locating the Linux/kitty OSC 99 notification emission in the TypeScript code and compare its fields with the captured sequences; done means the notification carries the requested application identity and icon metadata, verified with the dbus-monitor reproduction.