Fix API key race: wait inside ensureBridgeStarted, not callers

[kodjima33]

Summary

Previous fix (#5987) added waitForKeys() in OnboardingChatView before sendMessage(), but the bridge was already started by ViewModelContainer.warmupBridge() → ensureBridgeStarted() — 26ms before keys loaded. The bridge launched in Mode B (no API key) every time.

Root cause: ensureBridgeStarted() calls acpBridge.start() which spawns a subprocess that reads ANTHROPIC_API_KEY from environment. If the key isn't set yet, it starts in OAuth mode — which fails for new users who don't have a Claude account.

Fix: Move waitForKeys() into ensureBridgeStarted() itself, right before acpBridge.start(). One place, covers all callers. Also store fetchTask from OmiApp launch so waitForKeys() can always await it.

Test plan

• Clean install → sign in → verify bridge starts in Mode A (check log for "Mode A (Omi API key)")
• Verify onboarding chat works without Claude OAuth session

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR consolidates the waitForKeys() call into ensureBridgeStarted() itself so the ACP bridge always waits for ANTHROPIC_API_KEY to be set before launching the subprocess, fixing the race condition where the bridge started in Mode B (OAuth) instead of Mode A (Omi API key). It also stores the fetchTask handle on APIKeyService so that waitForKeys() can always await the in-flight fetch regardless of which code path triggered the bridge start.

Changes:

• APIKeyService.swift — private var fetchTask changed to private(set) var fetchTask; startFetchingKeys() helper removed.
• OmiApp.swift — assigns APIKeyService.shared.fetchTask directly instead of spawning a fire-and-forget Task {}.
• OnboardingChatView.swift — removes both waitForKeys() call-sites (bridge warmup path and fresh-start sendMessage path).
• ChatProvider.swift — adds waitForKeys() inside ensureBridgeStarted(), guarded by acpBridge.passApiKey, as the single canonical wait point.

Issue found:

• fetchTask is declared private(set), but OmiApp.swift writes to it from a different file — Swift's private(set) restricts the setter to the enclosing type and same-file extensions only, so this will not compile. The setter access level must be changed to internal (i.e., just var fetchTask).

Confidence Score: 3/5

• Not safe to merge as-is — the private(set) access modifier on fetchTask will prevent the module from compiling.
• The logic of the fix is correct and the architectural approach (centralising the wait inside ensureBridgeStarted) is sound. However, the access-control change on APIKeyService.fetchTask (private var → private(set) var) introduces a hard compile error: Swift's private(set) only allows the setter within the enclosing type/same-file extensions, yet OmiApp.swift writes to it from AppDelegate. Changing private(set) to plain var (internal setter) is a one-line fix, after which the PR should be safe to merge.
• desktop/Desktop/Sources/APIKeyService.swift — setter access level must be corrected from private(set) to var before this compiles.

Important Files Changed

Filename	Overview
desktop/Desktop/Sources/APIKeyService.swift	Changed private var fetchTask to private(set) var fetchTask, but private(set) still prevents OmiApp.swift from writing to the property — this will cause a compile error.
desktop/Desktop/Sources/OmiApp.swift	Stores the fetch task in APIKeyService.shared.fetchTask so waitForKeys() can always await it. Assignment will fail to compile unless fetchTask's setter access level is corrected in APIKeyService.swift.
desktop/Desktop/Sources/OnboardingChatView.swift	Correctly removes the two waitForKeys() calls that were previously needed before bridge warmup and sendMessage; comment updated to point to internal handling in ensureBridgeStarted.
desktop/Desktop/Sources/Providers/ChatProvider.swift	Adds waitForKeys() inside ensureBridgeStarted() guarded by acpBridge.passApiKey, placing the wait at the correct single chokepoint before the subprocess is launched.

Sequence Diagram

sequenceDiagram
    participant OmiApp
    participant APIKeyService
    participant ChatProvider
    participant ACPBridge

    OmiApp->>APIKeyService: fetchTask = Task { fetchKeys() }
    Note over APIKeyService: fetchTask stored for awaiting

    OmiApp->>ChatProvider: warmupBridge() [via ViewModelContainer]
    ChatProvider->>ChatProvider: ensureBridgeStarted()
    alt acpBridge.passApiKey == true
        ChatProvider->>APIKeyService: waitForKeys()
        APIKeyService-->>ChatProvider: (keys loaded)
    end
    ChatProvider->>ACPBridge: start()
    Note over ACPBridge: Reads ANTHROPIC_API_KEY<br/>→ launches in Mode A

    OmiApp->>ChatProvider: sendMessage(...)
    ChatProvider->>ChatProvider: ensureBridgeStarted()
    Note over ChatProvider: guard !acpBridgeStarted → returns true immediately

Loading

Comments Outside Diff (1)

1. desktop/Desktop/Sources/APIKeyService.swift, line 23 (link)

   private(set) blocks external write — compile error

   OmiApp.swift sets APIKeyService.shared.fetchTask = Task { ... } from AppDelegate, which is a different file. In Swift, private(set) restricts the setter to the enclosing declaration and same-file extensions only. External files like OmiApp.swift cannot call the setter, so this will produce a compiler error:

   error: cannot assign to property: 'fetchTask' setter is inaccessible

   The setter access level should be removed (defaulting to internal) so that OmiApp.swift can assign it:

_{Reviews (1): Last reviewed commit: "fix(desktop): wait for API keys inside e..." | Re-trigger Greptile}