macOS: no way to opt out of Jcode.app / notification broker bundles

Summary

On macOS, a CLI-only install still gets two app bundles created in ~/Applications:

• Jcode.app (launcher, com.jcode.launcher)
• Jcode Notifications.app (notification broker)

There does not appear to be a way to opt out. Deleting them is not persistent: they are recreated on the next TUI start.

I installed jcode as a terminal tool and would like a supported way to keep it that way.

Environment

• jcode v0.75.0 (5ae238574), stable channel
• macOS 26.6.1 (25G76), Apple Silicon (aarch64)
• Terminal: Ghostty 1.3.1
• Installed at ~/.local/bin/jcode

Steps to reproduce

1. Remove both bundles from ~/Applications.
2. Start the jcode TUI, then quit.
3. Both bundles are present again.

What I checked first

I wanted to be sure I had not just missed a setting:

• No key under [display], [features], or [safety] controls bundle creation.
• safety.desktop_notifications = false and notifications.turn_complete = false do not prevent the broker bundle. Creation does not appear to be gated on notifications being enabled at all.
• launch_hotkeys.enabled = false (and removing the hotkey LaunchAgent) does not prevent Jcode.app.
• CLI subcommands such as jcode version, jcode session list, and jcode usage do not trigger creation. Only the TUI startup path does.
• JCODE_MACOS_NOTIFICATION_BROKER_APP exists in the binary, but as far as I can tell it only affects the send path; macos_notification_broker_dir() in crates/jcode-setup-hints/src/macos_launcher.rs (lines 121-124) hardcodes ~/Applications, so it cannot relocate the bundle.

Looking at should_refresh_macos_app_launcher() (lines 18-30 and 315-323), refresh happens when desktop_shortcut_created is false, when either bundle fails its validity check, or when a legacy bundle exists. For the launcher, macos_app_launcher_is_valid() (lines 276-281) is a file-existence check, so a deleted bundle is indistinguishable from a corrupted one and gets repaired. The broker additionally checks a version marker (macos_notification_broker_is_valid(), lines 147-154), so it is also reinstalled after every upgrade. Self-healing makes sense; there just seems to be no way to express "I removed this deliberately".

The only workaround I found is to occupy both paths with immutable zero-byte files so creation fails. jcode handles the failure gracefully, which is nice, but obviously not a supported configuration path.

Possible directions

Any of these would work for my case:

• A config key to skip bundle creation for CLI-only installs.
• Gating the broker bundle on desktop_notifications = false.
• Placing the helper bundles under ~/.jcode/ instead of ~/Applications, where the rest of jcode's runtime state already lives.

#215 (closed) raised the ~/Applications/Jcode.app surprise for the installer path and was addressed with an icon. This is the same surprise from the TUI startup path, from the angle of wanting no bundles at all.

This is macOS-specific and easy for me to test here, so I am glad to check any behavior or provide more detail if useful.

Start in crates/jcode-setup-hints/src/macos_launcher.rs, reading should_refresh_macos_app_launcher(), macos_app_launcher_is_valid(), macos_notification_broker_dir(), and macos_notification_broker_is_valid(). Trace the TUI startup path and configuration handling before choosing among the proposed opt-out approaches. Done means a supported CLI-only configuration prevents both bundles from being created or recreated, with the behavior verifiable on macOS.