Before submitting
Area
apps/web
Problem or use case
Users who switch between recurring local Settings configurations must manually remember and reapply many preferences. Copying whole settings objects is unsafe because credentials, provider/network configuration, project paths, per-thread automation state, native controls, telemetry, and future private fields must never be bundled into a convenience profile.
Proposed solution
Add a deliberately minimal local named-profiles flow:
- save the current allowed client preferences under a normalized name;
- apply a saved profile through the existing Settings state path;
- show the saved profiles in Settings with accessible status feedback;
- persist locally with strict count/size limits, refresh-before-write, storage-event refresh, and a Web Locks wrapper where available;
- use an exhaustive fail-closed allowlist so unknown future settings and sensitive/project/thread-specific fields are excluded.
This first slice intentionally omits rename, delete, import/export, syncing, server storage, credentials, provider/model/network security, project paths, exact-thread automation, legacy minute fields, media assets, native controls, pacing, and telemetry.
Why this matters
It makes repeatable local configurations convenient without turning a profile file into a credential, private-path, or automation-state exfiltration mechanism. The strict allowlist also fails closed when new settings are added later.
Smallest useful scope
Five files / 715 additions directly on current main: one bounded profile module and tests plus the minimal Settings panel integration and browser coverage. Save and apply are end-to-end useful; broader profile management stays deferred.
Alternatives considered
- Exporting the entire settings object is unsafe and not forward-compatible.
- Server-side profiles would add identity, authorization, synchronization, and privacy scope.
- Import/export in the first slice would expand untrusted-file parsing and browser download/upload behavior.
- A pure storage foundation without visible save/apply controls would not be useful by itself.
Risks or tradeoffs
The allowlist must be updated intentionally when safe new fields are added. Local storage is limited and can fail, so writes must be atomic from the UI state perspective. Cross-tab writes need refresh/serialization. This remains a non-trivial feature and maintainers may prefer a different product direction.
Examples or references
The broader independently audited implementation is John-Ryan21337/club-code PR #22. The prepared Cafe-main recut removes rename/delete/import/export to stay at 715 lines and below the repository warning.
Contribution
Before submitting
Area
apps/web
Problem or use case
Users who switch between recurring local Settings configurations must manually remember and reapply many preferences. Copying whole settings objects is unsafe because credentials, provider/network configuration, project paths, per-thread automation state, native controls, telemetry, and future private fields must never be bundled into a convenience profile.
Proposed solution
Add a deliberately minimal local named-profiles flow:
This first slice intentionally omits rename, delete, import/export, syncing, server storage, credentials, provider/model/network security, project paths, exact-thread automation, legacy minute fields, media assets, native controls, pacing, and telemetry.
Why this matters
It makes repeatable local configurations convenient without turning a profile file into a credential, private-path, or automation-state exfiltration mechanism. The strict allowlist also fails closed when new settings are added later.
Smallest useful scope
Five files / 715 additions directly on current main: one bounded profile module and tests plus the minimal Settings panel integration and browser coverage. Save and apply are end-to-end useful; broader profile management stays deferred.
Alternatives considered
Risks or tradeoffs
The allowlist must be updated intentionally when safe new fields are added. Local storage is limited and can fail, so writes must be atomic from the UI state perspective. Cross-tab writes need refresh/serialization. This remains a non-trivial feature and maintainers may prefer a different product direction.
Examples or references
The broader independently audited implementation is John-Ryan21337/club-code PR #22. The prepared Cafe-main recut removes rename/delete/import/export to stay at 715 lines and below the repository warning.
Contribution