fix(connections): migrate Salesforce to Agent Tools

[johnmatthewtennant]

Summary

Fix the Salesforce connection path for users whose bundled local MCP fails with No active HTTP request found. Retire the standard bundled Salesforce stdio server after backing up Goose configuration, preserving custom configurations. Each removal re-reads the entry by its configuration key and skips it if it disappeared or changed since the initial inventory.

Salesforce follows the existing Gmail pattern: the company-managed connector handles authorization, and users discover and install the Salesforce skill through the skill marketplace to use sq agent-tools salesforce-sq. Connections now explains those two steps. Connecting does not automatically install a skill. The remote MCP remains available.

Related issue

BOT-1789. No matching GitHub issue or PR found.

Testing

Reproduced get_current_user failing over stdio with No active HTTP request found; the authorized read-only Agent Tools call succeeds. Regression coverage verifies backup before removal, repeat-startup safety, and preservation of custom servers. Changed-during-backup cases fail against the old reconciliation and pass with the fix, including added tokens, custom arguments, renamed entries, and disappearing entries.

Drove startup and Settings → Connections in the built frontend using the repository's Tauri/ACP fixtures seeded with a bundled Salesforce server. Before, startup left the server in place. After, startup backs up and removes it, while the Salesforce (Square) connector remains visible alongside marketplace guidance. A second startup scenario adds a Salesforce token during backup: the customized entry remains, while the unchanged scenario still removes it. Native configuration and OAuth calls were stubbed in these browser journeys.

Verified the native macOS PR build with the real connected account: Connections shows Salesforce (Square) active, the marketplace installs salesforce-sq, and a fresh Berd chat loads that skill and successfully runs sq agent-tools salesforce-sq get-current-user. Only the identity check ran; no Salesforce business records or writes were involved. The real profile already lacked the retired local server, so native startup removal is covered by the isolated journey above.

Screenshots

Before

After

[morgmart]

🤖 Automated code review

Engineering found one blocking startup reconciliation race that can delete a Salesforce configuration changed after the initial inventory snapshot. The supplied GitHub evidence is structurally valid and all 11 reported checks passed. Recommend REQUEST_CHANGES.

Deterministic publication result: 1 blocking and 0 non-blocking inline finding(s) publishable; 0 duplicate(s) suppressed; 0 blocking screenshot-evidence requirement(s) in this review body.

[morgmart]

🤖 Automated code review

Engineering found no publishable changed-line issues in the exact PR comparison. The prior destructive-reconciliation race is fixed by re-reading and matching each current entry immediately before removal, with discriminating regression coverage. Supplied GitHub evidence is structurally valid; four checks passed and four were still in progress when captured. Recommend APPROVE; required checks still govern merge readiness.

Deterministic publication result: 0 blocking and 0 non-blocking inline finding(s) publishable; 0 duplicate(s) suppressed; 0 blocking screenshot-evidence requirement(s) in this review body.

Pending checks: 5 check(s) are not complete.

This approval reflects the completed code review only; merge readiness remains governed by the repository's required checks.