Description
When using Cap Desktop with a self-hosted Cap Web instance, the S3 configuration API calls (/api/desktop/s3/config/*) are sent to https://cap.so instead of the custom server URL configured in Settings.
This means users with self-hosted Cap instances cannot use the S3 Config feature in Cap Desktop, even though:
- Authentication works correctly with the self-hosted server
- The custom server URL is properly saved in settings
Root Cause
The desktop app has inconsistent URL handling:
Authentication (apps/desktop/src/utils/auth.ts:39) correctly reads the runtime setting:
const serverUrl =
(await generalSettingsStore.get())?.serverUrl ?? "https://cap.so";
API client (apps/desktop/src/utils/web-api.ts:35,44) uses a static build-time value:
export const apiClient = initClient(contract, {
baseUrl: `${clientEnv.VITE_SERVER_URL}/api`,
api,
});
Where clientEnv.VITE_SERVER_URL is defined in apps/desktop/src/utils/env.ts:
export const clientEnv = {
VITE_SERVER_URL: import.meta.env.VITE_SERVER_URL ?? "https://cap.so",
};
This is a build-time constant that defaults to https://cap.so and never reads from generalSettingsStore.serverUrl.
Reproduction
- Set up a self-hosted Cap Web instance
- In Cap Desktop, go to Settings > General and set Server URL to your self-hosted instance
- Sign in (this works because auth.ts uses the correct URL)
- Go to Settings > Integrations > S3 Config
- The page will fail to load or show errors because API calls go to
cap.so instead of your server
Expected Behavior
All API calls in the desktop app should respect the custom server URL setting, not just authentication.
Suggested Fix
Update apps/desktop/src/utils/web-api.ts to dynamically read from generalSettingsStore instead of using the static clientEnv.VITE_SERVER_URL. This may require making the API client initialization async or creating a function that returns the current server URL.
Additional Context
Description
When using Cap Desktop with a self-hosted Cap Web instance, the S3 configuration API calls (
/api/desktop/s3/config/*) are sent tohttps://cap.soinstead of the custom server URL configured in Settings.This means users with self-hosted Cap instances cannot use the S3 Config feature in Cap Desktop, even though:
Root Cause
The desktop app has inconsistent URL handling:
Authentication (
apps/desktop/src/utils/auth.ts:39) correctly reads the runtime setting:API client (
apps/desktop/src/utils/web-api.ts:35,44) uses a static build-time value:Where
clientEnv.VITE_SERVER_URLis defined inapps/desktop/src/utils/env.ts:This is a build-time constant that defaults to
https://cap.soand never reads fromgeneralSettingsStore.serverUrl.Reproduction
cap.soinstead of your serverExpected Behavior
All API calls in the desktop app should respect the custom server URL setting, not just authentication.
Suggested Fix
Update
apps/desktop/src/utils/web-api.tsto dynamically read fromgeneralSettingsStoreinstead of using the staticclientEnv.VITE_SERVER_URL. This may require making the API client initialization async or creating a function that returns the current server URL.Additional Context