Desktop: using Maple chat disrupts the local API proxy (proxy stops and saved API key is scrubbed)

[AnthonyRonning]

User report (not yet reproduced)

A user reports that when they run the local OpenAI-compatible proxy built into the Maple desktop app and then use Maple chat in the same desktop app, the chat disrupts the API proxy. This has not been reproduced yet; this issue captures a code-level investigation so the repro work is better informed.

Investigated at commit 3f605ab7 (master, 2026-08-11).

What the code shows

Per AGENTS.md, research chat and Agent Mode do not route through the local proxy, so there is no intentional network-level interaction. The plausible coupling is instead the shared auth lifecycle, which can tear down the proxy as a side effect of chat-adjacent flows:

1. frontend/src/routes/__root.tsx (~L44, L52-56): the root route computes userId = auth.user?.user.id || null and calls transitionAgentAuthUser(userId) on every change.
2. frontend/src/services/agentRuntimeService.ts (~L455-478): the AgentAuthLifecycleCoordinator cleanup callback runs on any transition away from the current user and calls proxyService.stopAndResetProxy().
3. frontend/src/services/proxyService.ts (~L196-236) -> Rust stop_and_reset_proxy in frontend/src-tauri/src/proxy.rs: this aborts the proxy server task AND clears api_key, sets enabled = false and auto_start = false, then persists that to proxy_config.json. So the proxy is not just stopped - it is de-configured, and the user must create/enter a new API key to recover.

Chat-adjacent flows that trigger that cleanup path:

• Guest on free plan tries to chat -> GuestPaymentWarningDialog ("Subscription Required", shown from frontend/src/routes/index.tsx ~L117-127) -> its Log Out path calls proxyService.stopAndResetProxy(userId, os.deleteApiKey) (GuestPaymentWarningDialog.tsx ~L57-58), which also remotely revokes tracked keys.
• Unverified (non-guest) account -> VerificationModal blocks the home/settings routes (__root.tsx ~L101) -> its Log Out path also calls stopAndResetProxy (VerificationModal.tsx ~L137-138).
• Guest -> full account conversion or account switch changes user.id, so the root effect runs the previous account's cleanup and scrubs the proxy.
• Any transient auth.user === undefined (e.g. a failed refetchUser, session loss during/after a chat) flips userId to null, which also runs the full cleanup and scrubs the proxy.

So a plausible reading of the report: the user starts the proxy (manually created API key, saved in proxy_config.json), then uses chat, hits one of the flows above (payment wall, verification, account transition, or session hiccup), and the proxy is stopped with its saved credential wiped - looking like "the chat broke the proxy".

Related history (this area has been touched repeatedly)

• Harden the credential-backed Local Proxy against arbitrary browser origins #654 (closed) - Harden the credential-backed Local Proxy against arbitrary browser origins
• Fence manual proxy startup against logout and account transitions #655 (closed) - Fence manual proxy startup against logout and account transitions
• Recover manual Local Proxy setup after logout without orphaning API keys #656 (closed) - Recover manual Local Proxy setup after logout without orphaning API keys
• d66c181f - "Clear proxy config on logout to prevent auto-start without auth"

The scrub-on-logout behavior is intentional; the suspicion here is that chat flows trigger it unexpectedly, or that scrubbing the manually configured credential is too destructive when the proxy was set up by hand.

Info that would help a repro

1. Account type: guest/anonymous or full account? Email verified?
2. Did a "Subscription Required" or "Verify Your Email" dialog appear around the time chat was used?
3. After the disruption: is the proxy process stopped (connection refused on 127.0.0.1:8080), and is api_key empty / enabled: false in proxy_config.json (app config dir, or legacy ~/.config/maple/proxy_config.json)?
4. OS, app version, and app logs from a session where it happened.
5. Was the proxy started manually from Settings, or auto-started / Agent-managed?

Possible directions (not a proposed fix)

• Decouple proxy teardown from generic auth-user transitions: only scrub credentials on explicit sign-out / account deletion, and consider stopping the listener without wiping a manually configured api_key.
• Distinguish Agent-owned proxy keys from manually created ones when deciding what to scrub/revoke (partially exists via the tracked-key registry in proxyService.ts).
• Regression test: start the local proxy, send a chat message (incl. guest/free-plan and unverified-account variants), assert the proxy is still running and its config is intact.

[AnthonyRonning]

Narrowing from reporter follow-up

New info from the affected user: paid team-plan account, usage remaining, verified email, Agent Mode not in use.

Ruled out by this

• GuestPaymentWarningDialog ("Subscription Required") logout path - guest accounts only.
• VerificationModal logout path - email is verified.
• Guest -> full account conversion changing user.id - N/A.
• Agent Mode runtime and token-sync paths (mapleApiAuthService, embedded Goose setup) - Agent Mode not in use. Note: the transitionAgentAuthUser cleanup in agentRuntimeService.ts is still armed on desktop without Agent Mode, but it only fires on an auth-user change.

Also checked: the backend does not couple these

In OpenSecret (src/web/openai_auth.rs), chat authenticates by JWT and the proxy by API key through fully independent branches, and API keys are only deleted by the explicit user-initiated delete_api_key route. No backend path where chat usage revokes or disables an API key. So "chat invalidates the proxy's key" is not supported by source.

Remaining candidates, in order of plausibility

1. Auth-lifecycle scrub (Maple, this issue's main hypothesis). Still the only Maple path that both stops the proxy and wipes api_key from proxy_config.json. For a stable paid user it requires auth.user to change mid-session: session loss (e.g. a failed token refresh while chatting), account switch, or an explicit sign-out from Settings. Should not fire spontaneously, so logs are needed to confirm or eliminate it.
2. App restart without auto-start (Maple). auto_start defaults to false and manually starting the proxy from Settings does not enable it (ProxyConfigSection.tsx preserves the existing auto_start value on start). The proxy therefore does not survive an app quit/restart/update. If the user restarted the app around the time they were chatting, the proxy silently stays down with its config intact, and the correlation with chat would be spurious.
3. Enclave session staleness (unverified, backend/enclave side). The proxy caches an attested client per API key (client_for_api_key in maple-proxy), while the chat SDK attests independently. If the enclave invalidates older sessions (redeploy / PCR rotation), the proxy's cached client breaks while chat re-attests transparently. Presents as "proxy broken, chat fine" without chat actually causing it.

Decisive diagnostic for the reporter

Right after the disruption, before restarting anything:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health

• Connection refused -> the proxy server was stopped locally. Then check proxy_config.json (app config dir, or legacy ~/.config/maple/proxy_config.json):
  • api_key empty + enabled: false -> the auth-lifecycle scrub ran (candidate 1). App logs should contain "Stopping proxy".
  • config intact but proxy off -> app restart without auto-start (candidate 2).
• 401 -> the API key itself is being rejected (backend key validity, not Maple).
• 500 / "Failed to establish secure connection with Maple backend" -> attestation/session staleness (candidate 3).

App logs and the proxy_config.json state after a failure would distinguish these conclusively.

[AnthonyRonning]

Further narrowing: no sign-out or account switch

Reporter confirms the user did not sign out or switch accounts. That eliminates the auth-lifecycle scrub hypothesis entirely, and here's why we can say that conclusively:

• The only Maple code path that stops and de-configures the proxy is the auth-user transition cleanup (transitionAgentAuthUser -> stopAndResetProxy). It requires auth.user?.user.id to change.
• In @opensecret/react, auth.user only becomes undefined via explicit signOut() or a failed refetchUser(); a failed mid-session token refresh just throws (refreshToken() in the SDK does not clear tokens or user state). And when auth.user is undefined the root route renders the signed-out entry page - the user would have seen themselves logged out of chat. They kept chatting, so no transition fired.

Also verified: the desktop updater installs updates but does not auto-relaunch ("Will be applied on next application restart", lib.rs), so an auto-update can't silently kill the proxy either.

What remains

1. Enclave session staleness (leading hypothesis). maple-proxy caches an attested OpenSecretClient per API key with a 1-hour TTL (CLIENT_CACHE_ENTRY_TTL, proxy.rs). If the enclave drops or invalidates that session server-side within the hour, every proxied request fails until the cache entry expires or errors, while chat keeps working because the JS SDK maintains its own independent attested session. Whether chat activity actually triggers the invalidation (vs. coincidental timing, e.g. an enclave redeploy) is unverified and likely needs enclave-side input or a repro.
2. App quit/crash/restart without auto-start. auto_start defaults to false and manual start doesn't enable it, so any app termination leaves the proxy down with config intact. Less likely given the user would probably notice an app restart.
3. (Side finding) Proxy server-task death is masked by status. In frontend/src-tauri/src/proxy.rs, if the axum::serve task ever returns an error, the task ends but ProxyState.running stays true: get_proxy_status keeps reporting "running" and start_proxy early-returns without restarting. If the reporter saw Settings claim the proxy was running while the port was dead, this is why - and it's an independent robustness bug worth fixing regardless (check task liveness, don't trust the flag).

Updated diagnostic ask

After the disruption, before restarting anything:

curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health
curl -s http://127.0.0.1:8080/v1/models   # with and without the Authorization header

• Connection refused + proxy_config.json intact -> app terminated without auto-start, or server-task death (did Settings still show "running"?)
• 500 / "Failed to establish secure connection with Maple backend" -> attestation/session staleness (candidate 1)
• 401 -> the API key itself is being rejected by the backend
• Plus: app logs around the failure, and roughly how long the proxy had been up (the 1-hour client-cache TTL makes uptime relevant)

[AnthonyRonning]

Source-level clearing is now complete - and points at runtime evidence

Reporter also confirms no app crash/restart. Combined with the earlier constraints (paid team plan, verified email, no sign-out/switch, no Agent Mode), every chat->proxy coupling checkable from source is now cleared:

Maple frontend - the chat client (frontend/src/ai/OpenAIContext.tsx) points at VITE_OPEN_SECRET_API_URL directly with the SDK's encrypted fetch; it never touches localhost:8080, never invokes proxy commands, and never mutates auth state beyond token refresh (which does not change auth.user).

Maple native - the proxy is only stopped by explicit Tauri commands (stop_proxy, stop_and_reset_proxy), all of which trace to sign-out/account-transition UI the user never saw. The updater installs but never auto-relaunches.

Backend auth (opensecret openai_auth.rs) - chat (JWT) and proxy (API key) authenticate independently; API keys are only deleted by the explicit user-initiated route.

Enclave sessions - no per-account session limit; capacity is 2M sessions (MAX_ENCRYPTION_SESSIONS), so chat's new session cannot evict the proxy's. Idle TTL is 65 min with touch-on-use.

Session staleness self-heals - an unknown/expired session gets HTTP 400 from the enclave (acquire_session -> ApiError::BadRequest), and 400 is on the Rust SDK's attestation-retryable list (is_attestation_retryable), so the proxy's cached client transparently re-handshakes and retries, including on the SSE streaming path. A dead session cannot produce a persistent proxy outage.

Where that leaves this

No code path found where using chat disrupts the proxy. Remaining possibilities need runtime evidence, or the chat correlation itself is misleading (user notices a dead proxy while using both):

1. The one concrete Maple-side defect found: if the proxy's axum::serve task ever dies, ProxyState.running stays true (frontend/src-tauri/src/proxy.rs) - Settings keeps showing "running", and start_proxy early-returns without restarting. Any transient listener failure would look like a permanent, unfixable-from-UI outage. Worth fixing regardless: check task liveness instead of trusting the flag.
2. Environmental: another process binding :8080, VPN/firewall/security software interfering with loopback, machine sleep cycling network state.
3. An enclave-side behavior not visible from source (needs enclave logs for the user's API key around the failure window).

Evidence needed to proceed (unchanged, now decisive)

• curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health right after the disruption
• What the Settings proxy page showed at that moment ("running" while the port is dead => the status-masking bug above)
• proxy_config.json contents after the failure (config intact vs scrubbed)
• App logs around the failure ("Stopping proxy" would prove the teardown path ran; "Proxy server error" would prove the serve task died)
• OS and app version

[AnthonyRonning]

Re-assessment after the auth-recovery v2 stack (Aug 22)

Reviewed the recent changes across the stack: opensecret 2ac0795 (identify recoverable auth transport failures), SDK d4d0412 (retry recoverable encrypted requests once; JS 3.5.0 / Rust 3.6.2), maple-proxy 0.3.2 (pins opensecret = "3.6.2"), Maple master (pins maple-proxy = "0.3.2", uses the published recovery SDKs).

What improved: recoverable auth-transport failures are now a server-advertised contract (x-opensecret-error-contract: 1 + session_not_found / access_token_expired codes) that both SDKs classify and retry once, including the embedded desktop proxy via Rust SDK 3.6.2. Transient session/token failures are now less likely to surface as persistent proxy errors.

What did not change:

• Maple's proxy lifecycle code is untouched since this analysis (frontend/src-tauri/src/proxy.rs, proxyService.ts, __root.tsx unchanged). The status-masking defect is still live: a dead axum::serve task leaves ProxyState.running = true, Settings shows "running", and start_proxy no-ops.
• No new chat -> proxy coupling: SDK recovery never signs out or clears tokens when exhausted, and the Maple diff adds no signOut / stopAndResetProxy / stop_proxy call sites. The "no code path where chat disrupts the proxy" conclusion still holds.

One new hypothesis enabled by these changes: the backend now enforces model access by billing plan (da4cadb "Enforce model access by billing plan", plus plan-based automatic model aliases). For a team-plan user, a proxy client requesting a model outside the team's plan would now fail while chat (on plan-allowed models) keeps working - matching the "chat fine, proxy broken" shape without chat causing it. Worth asking the reporter exactly which model ID the external tool sends through the proxy, and whether /v1/models through the proxy lists it.

So: still a potential issue, but the plausible space narrowed further - remaining suspects are (1) the running-flag masking bug making any transient proxy failure look permanent, (2) plan-based model gating for this team user, (3) something environmental. The runtime evidence asks in the previous comment still stand.

[AnthonyRonning]

Consolidated analysis (summary of the comment thread)

Pulling the full analysis into one place for easier reading. The incremental details are in the comments above.

The report and constraints

A user runs the local OpenAI-compatible proxy in the Maple desktop app, then uses Maple chat in the same app, and the chat appears to disrupt the proxy. Known about the affected user: paid team-plan account, usage remaining, verified email, no Agent Mode, no sign-out or account switch, no app crash or restart.

Approach

Trace every conceivable path by which chat activity could affect the proxy, and check each against source. Per AGENTS.md, chat and Agent Mode never route through the local proxy, so any coupling has to be indirect: shared auth lifecycle, shared credentials, or shared backend sessions.

What was checked and cleared (with evidence)

1. Auth-lifecycle teardown (the initial prime suspect). __root.tsx runs transitionAgentAuthUser(userId) on every auth.user?.user.id change, and any transition away from the current user calls proxyService.stopAndResetProxy(), which stops the proxy and scrubs api_key from proxy_config.json. This is armed by guest-payment and email-verification dialogs, account conversion, and sign-out. Cleared: every trigger requires either a dialog the user never saw or a visible sign-out. In @opensecret/react, auth.user only goes undefined via explicit signOut() or a failed refetchUser() - a failed mid-chat token refresh just throws without touching user state (SDK api.ts), and an undefined user renders the signed-out entry page, which the user would have noticed.

2. Backend key invalidation. In opensecret openai_auth.rs, chat (JWT) and proxy (API key) authenticate through independent branches, and API keys are only deleted by the explicit user-initiated delete_api_key route. No path where chat usage revokes the proxy's key.

3. Enclave session interference. Sessions have no per-account limit and a 2M capacity (MAX_ENCRYPTION_SESSIONS), so chat establishing a session cannot evict the proxy's. Idle TTL is 65 min with touch-on-use. And a dead session is self-healing: the enclave returns HTTP 400 for an unknown session, which is on the Rust SDK's attestation-retryable list, so the proxy transparently re-handshakes (including on the streaming path).

4. Silent app restart. The updater installs but never auto-relaunches; the reporter says no crash/restart anyway. (Note: auto_start defaults to false, so any real app termination does leave the proxy down with config intact - kept on the list only as a general footgun.)

5. After the Aug 22 auth-recovery v2 stack (opensecret 2ac0795, SDK d4d0412, maple-proxy 0.3.2 on Rust SDK 3.6.2, Maple pinning proxy 0.3.2): recoverable failures are now a server-advertised contract (session_not_found / access_token_expired) retried once by both SDKs, further reducing transient-failure blast radius. Verified the Maple diff added no new signOut/stopAndResetProxy/stop_proxy call sites, and SDK recovery never signs out on exhaustion. frontend/src-tauri/src/proxy.rs is untouched.

Conclusion: no code path found where using chat disrupts the proxy. The chat correlation is likely coincidental (a dead proxy gets noticed while using both), environmental, or one of the two items below.

What remains on the table

1. Proxy status-masking bug (concrete Maple defect, still live on master). If the proxy's axum::serve task ever dies, ProxyState.running stays true: Settings shows "running", and start_proxy early-returns without restarting. Any transient listener failure becomes a permanent-looking, unfixable-from-UI outage. Worth fixing regardless of this report: check task liveness instead of trusting the flag.
2. Plan-based model gating (new since Aug 22). The backend now enforces model access by billing plan (da4cadb). A team-plan user whose external tool requests a model outside the team's plan would get failures through the proxy while chat on allowed models works - matching "chat fine, proxy broken" without chat causing it. Needs the reporter's exact model ID and the proxy's own /v1/models output.
3. Environmental / enclave-side factors not visible from Maple source (port conflict, loopback-interfering VPN/firewall, or enclave logs for the user's key).

Evidence that settles it

From the reporter, at the moment of disruption (before restarting anything):

• curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:8080/health - connection refused vs 401 vs 500 splits the tree
• What the Settings proxy page showed at that moment ("running" while the port is dead => the status-masking bug)
• proxy_config.json contents (intact vs scrubbed)
• App logs around the failure ("Stopping proxy" = teardown path ran; "Proxy server error" = serve task died)
• The exact model ID the external tool requests through the proxy
• OS and app version