fix(web): unify control sizing across settings pages

[juliusmarminge]

Problem

Settings rows mixed control heights freely: selects at 32px, inputs at 30px, buttons at 24/28/32px plus hand-pinned h-5/h-7/h-8 overrides, model pickers fixed at 28px, and the Keybindings page on its own compact scale. Integrations had three selects at one height and two at another; Project settings had five different heights in one column. Nothing in SettingsRow constrained the control slot, so every call site picked its own size.

Fix

Every settings surface now follows three tiers, documented above SettingsRow in settingsLayout.tsx:

• Row controls → size="sm" (Button, Select, Input, NumberField) or icon-sm. Every primitive's sm lands on the same 28px desktop / 32px mobile box, which is also where the model/traits pickers already sit.
• Section header actions and buttons inside list items, cards, toolbars → xs / icon-xs.
• Inline affordances (reset arrows, info tooltips, table-cell buttons, list reorder arrows) stay icon-micro.
• Dialog footers keep the app-wide default button size; the two settings dialogs that deviated were brought in line.

Small primitive changes: Switch gains a size="sm" variant that replaces the ad-hoc --thumb-size overrides (models list, branch toolbar), ServerUpdateAction gains a size prop, and FontFamilyPicker reuses selectTriggerVariants instead of a hand-copied trigger. The Keybindings when-clause expression builder stays on compact since it is a dense mono editor that was already internally consistent.

Before / after

General

Project settings

Integrations (three selects at one height, two at another → one)

Providers (instance card config fields)

Source control

Appearance

Keybindings, Connections, Archive, mobile

Verification

• Lint and typecheck on apps/web; ServerUpdateAction.test.tsx passes.
• Browser pass over every settings route and project settings at 1440px and 390px against a snapshot of real data (screenshots above).

Built with Claude Fable 5 via Claude Code.

🤖 Generated with Claude Code

---

Note

Low Risk
Visual and sizing-only changes across settings and shared UI primitives; no auth, data, or business-logic behavior changes.

Overview
Standardizes settings UI control heights by applying a documented three-tier sizing scheme (sm in row controls, xs/icon-xs in headers and list actions, icon-micro for tiny inline affordances) across settings routes and related surfaces.

Primitive and shared helpers: Switch adds size="sm" (replacing ad-hoc --thumb-size classes). ServerUpdateAction accepts a size prop (default xs; Connections passes sm for the primary server row). settingsLayout exports SETTINGS_PICKER_TRIGGER_CLASSNAME so model/traits pickers align with sm row controls. FontFamilyPicker uses selectTriggerVariants({ size: "sm" }) instead of duplicated trigger styles.

Call-site cleanup: Widespread migration from compact inputs/buttons/selects to sm, icon-micro toolbar buttons to icon-xs, and removal of manual h-5/h-7/h-8 overrides where size covers it. Keybindings moves most controls to sm/icon-xs while keeping dense editor behavior. Dialog footers in add-provider flow drop forced size="sm" to use default button sizing.

^{Reviewed by Cursor Bugbot for commit e71a6a0. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Unify control sizing to small across web settings pages

• Standardizes inputs, selects, switches, and buttons across all settings panels to use shared small sizing variants, replacing a mix of compact, micro, and custom per-component classes
• Adds a size prop (default default, sm) to the Switch component in switch.tsx with responsive thumb-size CSS variables and a data-size attribute
• Adds a shared SETTINGS_PICKER_TRIGGER_CLASSNAME constant in settingsLayout.tsx and replaces duplicated picker trigger class strings in ProjectSettingsPanel, GeneralSettingsPanel, and SourceControlWritingSettings
• Adds an optional button size prop to ServerUpdateAction (defaulting to xs) so settings callers can request small
• Risk: Switch default size is unchanged, but any out-of-tree or un-updated consumers passing thumb-size class overrides directly may no longer match the new responsive CSS variables; the ServerUpdateAction default remains xs so existing callers are unaffected

📊 Macroscope summarized e71a6a0. 20 files reviewed, 1 issue evaluated, 0 issues filtered, 1 comment posted

🗂️ Filtered Issues

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.4 KiB	13.2 KiB	−203 B (−1.5%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+3 B (+0.0%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.6 KiB	6.4 KiB	−206 B (−3.1%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	57.0 KiB	55.5 KiB	−1.5 KiB (−2.6%)	66.4 KiB	✅
Codex	Live turn messages	10	8	−2 (−20.0%)	21	✅
Claude	Total thread wire	13.2 KiB	13.3 KiB	+170 B (+1.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	+6 B (+0.1%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.3 KiB	6.4 KiB	+164 B (+2.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	55.5 KiB	56.4 KiB	+928 B (+1.6%)	66.4 KiB	✅
Claude	Live turn messages	8	10	+2 (+25.0%)	21	✅

Baseline: 535557b · PR result: e71a6a0 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.4 KiB
• Claude decoded thread snapshot: 110.1 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.

[macroscopeapp]

Approvability

Verdict: Approved at e71a6a0

Macroscope's review found this PR approvable — This is a presentation-only pass that standardizes control dimensions across existing settings screens without changing settings behavior, persistence, navigation, or backend actions. The shared component additions preserve existing defaults and introduce no new capability or sensitive configuration.

^{You can add or adjust custom eligibility rules. Learn more.}