[davidmckayv]

What

OpenBot Desktop 0.3.0 never got a Composio key from the CopilotKit sign-in. Every desktop install started with COMPOSIO_API_KEY empty, so apps were unavailable. This gets the key again, through the CLI the app already signs in with, and gives installs signed in under 0.3.0 a key on their next Start without signing in again.

Root cause

• feat(desktop): provision Composio projects during CopilotKit sign-in #971 asked Ops for this installation's Composio project during the app's own CopilotKit sign-in, kept the key in the protected store as COMPOSIO_PROVISIONED_API_KEY, and composio::resolve passed it to the server at Start.
• feat(desktop): standalone OpenBot with local CopilotKit Intelligence, from the app alone #832 replaced that sign-in with the bundled Intelligence CLI's login, and removed connect_apps, its IPC tests and the call to provision. resolve stayed, so Start would still have used a saved key, but nothing saved one.

Was it deliberate

Yes, for a reason that no longer holds. #832's description and docs/desktop-install.md say provisioning was left out because the Ops route it calls returned 404 in production. The route is live now: an unauthenticated POST /api/cli/integrations/composio/project gets 401 (the CLI session middleware), and a made-up route next to it gets 404. No credential was sent.

#832's design still holds. The CLI owns the CopilotKit account, and local_eval.rs never reads the CLI's credential files. So OpenBot doesn't call Ops itself. The CLI does, using the command Intelligence's Ops contract names for this (docs/contracts/openbot-composio-provisioning.md): copilotkit integrations composio provision --installation-id <UUID> --env-path <file> --json. The bundled CLI (256cc68) has it.

What changed

• CLI boundary (local_eval.rs): one more fixed command, integrations composio provision. Its arguments are a validated lowercase installation id and an absolute file path OpenBot made. The CLI's one line of metadata is believed only when it reports completed for the installation asked about, with the file written. Stderr is never read.
• Handoff (composio.rs): the CLI writes the key into ~/OpenBot/.openbot-apps/composio.env, an owner-only folder. OpenBot reads the key, checks the report, saves it to the protected store and removes the folder, whatever the CLI did. A folder an interrupted attempt left behind is cleared before the next one. The key is never written to .env. The direct Ops request and its HTTP test helper are removed, so the CLI is the only client.
• Account step (CopilotKitAccount.tsx, connect_copilotkit_apps): once the person is signed in and has agreed, it connects apps and shows "Connecting your apps…". On a failure it shows the existing "OpenBot couldn't connect your apps…" sentence, with Connect apps to retry and Continue to go on without apps.
• Start (persist_start_environment): an installation with local Intelligence and no key tries again before the broker keys are resolved. That covers installs signed in under 0.3.0. A failure is logged and never stops Start.
• Unchanged from feat(desktop): provision Composio projects during CopilotKit sign-in #971: a key the person supplied in .env or the environment always wins and is never moved, and so does an Arcade choice. Neither causes a request. Ops replays the same key for an installation (reused: true), so retries never make a second project.
• Docs: docs/desktop-install.md and docs/plugins/composio.md now describe this flow.

Tests

• Start regression (composio_ipc_tests.rs, a_copilotkit_sign_in_gives_start_a_composio_key):
  • Setup: an installation signed in under 0.3.0, with local Intelligence recorded and no key.
  • The CLI is a pinned stand-in that behaves like integrations.ts: it reads its own session, posts {"installationId"} with that bearer to a fake Ops on 127.0.0.1, and writes the key into the file it was given.
  • The fake Ops answers installationId, projectId, apiKey, reused as the contract describes.
  • Checks: Start hands the server the key, the key is in the protected store and not in .env, no handoff folder is left behind, and the next Start asks nobody.
  • Fails on main (left: None, right: Some("synthetic-project-key")) and passes here.
• IPC through the generated handler:
  • Signed out, the command fails with the sentence the window shows, and nothing is saved.
  • Signed in, Connect apps keeps the key, and a later call asks nobody.
  • A supplied key wins and causes no CLI call. An Ops 503 leaves Start succeeding with no key.
• Unit tests: fixed arguments, id validation and report checks in local_eval.rs. The handoff (failures, mismatched reports, leftover folders, replay) and the retry round trip in composio.rs.
• Window: the account step connects apps with the installation folder. On a failure it shows the sentence, Connect apps retries, and Continue goes on. The three window tests fail against main's window code.
• Real CLI contract: the pinned CLI (256cc68 from pkg.pr.new) was run against a fake Ops on 127.0.0.1, with a synthetic session in a scratch COPILOTKIT_CONFIG_DIR.
  • Its stdout, env file (0600, lock removed), signed-out exit 1 and Ops request match what the code and the fakes expect.
  • It was not run against production Ops, and no real CopilotKit sign-in was done.
• Commands:
  • cargo fmt --check and cargo clippy --all-targets -- -D warnings: clean.
  • cargo test: 814 + 195 + 7 pass.
  • Desktop tsc --noEmit: clean.
  • bun test desktop/src: 261 pass.
  • bun run format:check and bun run lint: clean.