Generic error on S3 integration (Desktop)

[pulgueta]

Description

I want to setup Cloudflare R2 to use it as my main bucket for storage and I went to configure it in the desktop app, but it crashed and doesn't work even when reloading.

Reproduction

Open Cap Desktop -> Integrations -> S3 Config -> Configure -> Joink

Error copied:

Error: Failed to fetch S3 config

@tauri://localhost/_build/assets/s3-config-RlCqiTlF.js:1:3123

Additional Context

• Cap version: v0.4.84
• Operating system, version: macOS 26.4.1
• Device (optional):MBP M4

[linear]

CAP-710

[tembo]

This error occurs when the desktop app's API call to /api/desktop/s3/config/get returns a non-200 status. Looking at the code path:

1. Desktop side (apps/desktop/src/routes/(window-chrome)/settings/integrations/s3-config.tsx:31-42): The createResource fetches config from apiClient.desktop.getS3Config() and throws when status !== 200
2. Server side (apps/web/app/api/desktop/[...route]/s3Config.ts:142-210): The GET handler requires authentication via withAuth middleware and queries the user's S3 bucket configuration

Most likely causes:

• Authentication issue: If the auth token is missing, expired, or invalid, the server returns 401 and the desktop shows this generic error. Check that you're signed in (Settings > General should show your account).

• Related to [Bug] Desktop app S3 config API calls ignore custom server URL setting #1485: If you're using a self-hosted instance, the desktop app's API client uses a hardcoded VITE_SERVER_URL (defaulting to https://cap.so) instead of respecting your custom server URL setting. The auth flow reads from generalSettingsStore.serverUrl, but the API client doesn't - see apps/desktop/src/utils/web-api.ts:34-36 vs apps/desktop/src/utils/auth.ts.

To narrow down the issue:

1. Check the desktop logs at /Users/{username}/Library/Logs/so.cap.desktop for the actual HTTP response
2. Open the network tab in DevTools (Help > Toggle Developer Tools) when navigating to S3 Config to see the actual response status and body from the API

If you're on the standard cap.so cloud service, this is likely an auth/session issue. If self-hosted, it's almost certainly the hardcoded URL problem from #1485.