Feature Request: Add an option to prevent MCPProxy Core from starting automatically with the macOS tray app

[jagaliano]

Feature Description

Add a macOS app preference that allows the tray app to launch without immediately starting the MCPProxy Core server process.

Today, opening the macOS tray app automatically starts or attaches to the Core process. Users can stop the Core manually afterward, but the stopped state is not persisted across app launches. A user who wants MCPProxy available in the menu bar, but does not currently need any AI/MCP client, cannot keep the tray app open without also starting the Core and its downstream MCP server process tree.

The requested feature is a persistent user setting such as:

Start MCPProxy Core when app opens: On/Off

or:

Start Core automatically: On/Off

When disabled, the tray app should open in a stopped/idle state and expose the existing manual action:

Start MCPProxy Core

Motivation

MCPProxy Core can keep a significant process tree alive, especially when configured upstream MCP servers start eagerly. In one observed setup, the MCPProxy process tree, including child MCP server processes, used approximately 1.8 GB RSS.

This is wasteful if the user wants the MCPProxy tray app available but is not currently using any AI application or MCP client.

A lazy/manual Core startup mode would allow users to:

• Keep the lightweight tray UI available.
• Avoid starting the Core server until needed.
• Avoid keeping configured upstream MCP child processes alive unnecessarily.
• Reduce memory usage during normal desktop sessions.
• Keep Login Items enabled for the tray app without also forcing the Core to run immediately at login.

This is especially useful for users who only occasionally launch AI clients but still want MCPProxy to be easy to start from the menu bar.

Current Behavior

The macOS tray app currently starts the Core unconditionally during app launch.

Relevant file:

native/macos/MCPProxy/MCPProxy/MCPProxyApp.swift

In applicationDidFinishLaunching, the app calls:

// Start core
Task {
    await startCore()
}

startCore() then creates a CoreProcessManager and starts it:

private func startCore() async {
    await notificationService.setup()
    await MainActor.run {
        appState.autoStartEnabled = AutoStartService.isEnabled
    }

    if SymlinkService.needsSetup() {
        if let bundledBinary = resolveBundledCoreBinary() {
            await SymlinkService.updateSymlinkIfNeeded(bundledBinary: bundledBinary)
        }
    }

    let manager = CoreProcessManager(
        appState: appState,
        notificationService: notificationService
    )
    coreManager = manager
    await manager.start()
}

CoreProcessManager.start() checks for an existing socket and attaches to a live Core if present. Otherwise, it launches a new Core subprocess:

func start() async {
    if SocketTransport.isSocketAvailable(path: socketPath) {
        if await probeExternalCore() {
            await attachToExternalCore()
            return
        }
        try? FileManager.default.removeItem(atPath: socketPath)
    }

    await MainActor.run { appState.ownership = .trayManaged }
    await launchAndConnect()
}

The subprocess launch path eventually runs:

proc.executableURL = URL(fileURLWithPath: binaryPath)
proc.arguments = ["serve"]

So the current launch sequence is effectively:

applicationDidFinishLaunching
  -> startCore()
    -> CoreProcessManager.start()
      -> launchAndConnect()
        -> launchCore()
          -> mcpproxy serve

Existing Manual Start/Stop Support

The app already has UI and state support for manually stopping and starting the Core.

Relevant state:

native/macos/MCPProxy/MCPProxy/State/AppState.swift

/// Whether the user has explicitly stopped MCPProxy (distinct from idle/error states).
@Published var isStopped: Bool = false

Relevant menu behavior:

native/macos/MCPProxy/MCPProxy/MCPProxyApp.swift

When stopped, the menu shows:

Start MCPProxy Core

When running, the menu shows:

Stop MCPProxy Core

The main window banner also supports starting the Core by posting:

NotificationCenter.default.post(name: .startCore, object: nil)

However, isStopped is currently in-memory only. It is not persisted with UserDefaults, so stopping the Core only affects the current app session. On the next app launch, Core starts automatically again.

Expected Behavior

Users should be able to configure whether the macOS tray app starts the Core automatically.

Example expected behavior:

1. User disables Start MCPProxy Core when app opens.
2. User quits MCPProxy.
3. User launches MCPProxy again, or macOS launches it via Login Items.
4. Tray app starts, but Core does not start automatically.
5. Tray menu/main window show a stopped/idle state.
6. User can manually start Core with the existing Start MCPProxy Core action.
7. Once started, existing behavior continues as normal.

Suggested UX

Possible UI labels:

Start Core on App Launch

or:

Start MCPProxy Core automatically

Possible placement:

• Tray menu near Run at Startup.
• Settings/preferences section in the main window.

This setting should be separate from Run at Startup / Login Item behavior:

• Run at Startup: controls whether the tray app launches at macOS login.
• Start Core on App Launch: controls whether the Core server starts when the tray app opens.

Proposed Implementation Direction

One possible implementation would be to add a persisted preference, for example via UserDefaults, and use it to decide whether applicationDidFinishLaunching calls startCore().

The app already uses UserDefaults for persisted UI state such as fontScale, so this would fit the existing pattern.

Example concept:

@Published var startCoreOnLaunch: Bool = UserDefaults.standard.object(forKey: "startCoreOnLaunch") as? Bool ?? true {
    didSet { UserDefaults.standard.set(startCoreOnLaunch, forKey: "startCoreOnLaunch") }
}

Then app launch could choose between:

if appState.startCoreOnLaunch {
    Task { await startCore() }
} else {
    appState.isStopped = true
}

The default should probably remain true to preserve current behavior for existing users.

This is only a possible implementation sketch; maintainers may prefer a different state/config structure.

Alternatives Considered

Use the existing Stop action after launch

This works only after Core has already started. It does not avoid the startup memory/process cost, and it does not persist across launches.

Disable Run at Startup

This prevents the tray app from launching at login, but it does not solve the case where the user wants the tray app available without starting Core immediately.

Rely on external process management

Users could avoid opening the app or manually kill the Core process, but that bypasses the app’s own lifecycle/UI and is not a good user experience.

Scope / Effort Estimate

Medium.

Likely touched areas:

native/macos/MCPProxy/MCPProxy/MCPProxyApp.swift
native/macos/MCPProxy/MCPProxy/State/AppState.swift
native/macos/MCPProxy/MCPProxy/Menu/TrayMenu.swift
native/macos/MCPProxy/MCPProxy/Views/MainWindow.swift

Potential test coverage areas:

• Default setting remains enabled for backward compatibility.
• When disabled, applicationDidFinishLaunching does not call startCore() automatically.
• Existing manual Start MCPProxy Core action still starts Core correctly.
• Existing manual Stop MCPProxy Core action still stops Core correctly.
• Run at Startup remains independent from Start Core on App Launch.

Additional Context

This feature is related to resource usage and lazy startup behavior. It is particularly relevant for users with many configured MCP upstream servers or upstreams that eagerly launch heavy child processes.

Current source inspection found no existing persisted setting or environment option to prevent Core startup on macOS app launch. The app has session-level stop/start behavior, but automatic startup is currently hardcoded in applicationDidFinishLaunching.

[Dumbris]

This is an excellent write-up — you read the code correctly, and your proposed design is essentially what we implemented. Apologies for the long silence.

Implemented in #847: a persisted Start MCPProxy Core when the app opens toggle in Settings → Startup, default ON so existing installs are unchanged. It sits next to Launch MCPProxy at login and is deliberately independent of it, exactly as you argued: app at login and core at app launch are different questions.

Two things worth reporting back, since you did the archaeology on this:

1. The Go tray already had this flag. MCPPROXY_TRAY_SKIP_CORE=1 has been in cmd/mcpproxy-tray/main.go (with a three-way ownership model) and documented in docs/architecture.md all along — it just never made it into the Swift app we actually ship on macOS. So this turned out to be a parity gap rather than a new feature. The new preference honours the same env var.

2. The design constraint that shaped it. The tray and core are decoupled — they talk only over the Unix socket / HTTP — so this setting cannot live in the core’s config: the whole point is to read it when no core is running, and then there is nothing to ask. It is tray-local (UserDefaults), like fontScale. Importantly, that does not make the tray stateful about the core: it never remembers whether a core is running (still discovered live from the socket on every launch), only its own permission to spawn one.

attach to a running core  — always allowed, never gated
spawn a new core          — gated by the preference

So with the toggle off and no core up, the tray idles and watches the socket — meaning a core you start yourself later (CLI, launchd, brew services) is picked up automatically, without restarting the tray. An explicit Start MCPProxy Core from the menu always spawns.

On your suggestion to persist isStopped: we went with the explicit toggle only, and left Stop as session-only. Two sources of truth for one behaviour can disagree (toggle ON, last action was Stop — what should launch do?), and a sticky Stop means stopping the core once to debug something can leave the tray dead after a reboot with nothing explaining why.

Your report also led us to two genuine bugs in that area, now fixed in the same PR:

• Stop MCPProxy Core was lying when attached to an external core. It tore down the tray’s own clients, displayed "Stopped", and left the core running (we hold no PID for it, and the core exposes no shutdown endpoint). It is now Disconnect from Core and says what it does.
• The Go tray killed cores it never started. If it found a core already running and attached to it, quitting the tray still terminated it — via the PID from /status and a pgrep -f "mcpproxy serve" sweep. So running a core under launchd and opening the tray meant quitting the tray killed your core. Only tray-spawned cores are terminated now.

Thanks for the detailed analysis — including the ~1.8 GB RSS measurement, which made the case concrete.

[jagaliano]

Thank you you for taking the time to write this up in such detail — I'm the one who's glad to help.

Really appreciate you closing the loop on the Go tray parity gap and the design reasoning around keeping
isStopped session-only — that trade-off makes sense and I'm glad it was thought through rather than just bolted
on.

Thanks again for the excellent work, and for making MCPProxy better for everyone. Looking forward to trying it
out once it ships!