You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feature request: the Global settings surface should mirror the Project settings surface (same sections/fields), so the same controls are available at both scopes. Two specific points:
Authentication at project level: settings traditionally considered "global-only" (notably Authentication / provider API keys) should be allowed at the project level. Use case: a user doing contract/dev work may want to bill a client's API keys only for that client's project, while keeping personal keys global for everything else.
Caveat acknowledged
Some settings genuinely operate at a platform/global level only (e.g. anything tied to the host machine or user account rather than a workspace). Those should remain global-only and be clearly marked — they shouldn't be forced into project scope.
Why
Consistency: users expect the same knobs in both places, with project overriding global.
Client billing: project-scoped auth keys are important for anyone running client work where dev costs must be billed to the client's account, not the developer's.
Summary
Feature request: the Global settings surface should mirror the Project settings surface (same sections/fields), so the same controls are available at both scopes. Two specific points:
buildTimeoutMs/insightExtractionEnabledhave no UI at all — see feat(dashboard): expose build timeout & insight extraction settings in the UI #1935/Allow build timeout & insight extraction to be set as global (user-level) defaults #1938).Caveat acknowledged
Some settings genuinely operate at a platform/global level only (e.g. anything tied to the host machine or user account rather than a workspace). Those should remain global-only and be clearly marked — they shouldn't be forced into project scope.
Why
Environment