Repository navigation
feat(settings): move Permissions for new chats into the Chat page's Behavior section - #28212
Conversation
…ehavior section The new-chat permission default sat alone above Appearance with its own header. It is a behaviour choice, so it now renders as the first row of the Behavior card, laid out like the rows already there. Its search entry and section id are unchanged, so search and deep links still land on it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to
|
…ehavior section (stablyai#28212) The new-chat permission default sat alone above Appearance with its own header. It is a behaviour choice, so it now renders as the first row of the Behavior card, laid out like the rows already there. Its search entry and section id are unchanged, so search and deep links still land on it. (cherry picked from commit f844518)
…ehavior section (#28212) The new-chat permission default sat alone above Appearance with its own header. It is a behaviour choice, so it now renders as the first row of the Behavior card, laid out like the rows already there. Its search entry and section id are unchanged, so search and deep links still land on it. (cherry picked from commit f844518)
ELI5
The Chat settings page has a "Permissions for new chats" picker. It sets whether new Claude and Codex chats ask before running commands or just run them. Today it sits alone at the very top of the page with its own heading, above Appearance. It's a choice about how chats behave, so this PR moves it into the Behavior section as that section's first row.
What Changed
Before: Settings → Chat opened with a standalone "Permissions for new chats" heading and picker, then Appearance, then Behavior.
After: Settings → Chat shows Appearance, then Behavior. Behavior's first row is "Permissions for new chats", with the same description and picker, laid out like the other Behavior rows. That's a label and description on the left and the control on the right.
Mechanism:
ChatPermissionSettingnow renders aSettingsRow, the row layout the Behavior card already uses, instead of a section heading.ChatBehaviorSettingrenders that row first inside its card. It counts the row toward its search matching, so searching "permissions" still shows the Behavior section.ChatSettingsSectionno longer renders it at the top.The setting itself, its search entry and its
chat-permissionssection id are unchanged. So search, deep links and the value are unaffected.Why
The control describes how chats behave, and the Behavior card is where the other chat behaviour switches live (resume after restart, queue follow-ups, shell environment). This reuses that card's existing row instead of keeping a one-off heading.
Linked Issue
Follow-up to #26116 and #28100 (STA-10345).
Visual Proof
Captured from hidden Electron dev builds on separate throwaway profiles at the same 1728 × 1200 renderer viewport.
Before (
f0ccfcc0d32, merge base with main): the permission picker sits above Appearance, outside Behavior.After (
f6ab055cf99): the picker is the first row in Behavior, with the description on the left and the control on the right.Search: searching settings for “permissions” finds the row inside Behavior.
Manually checked the rendered screenshots and opened the permission menu through the settings row. No clipping or overlap in the changed row. This capture covers macOS dark mode; other platforms, light mode, and agent execution were not exercised.
Testing
ChatBehaviorSetting.test.tsx: the permission picker is the first Behavior row, and the row is left out when the host has no value. The tests now render inside the app'sTooltipProvider, because the picker uses a tooltip.ChatPermissionSetting,ChatSettingsSection(including navigation and inline visuals) tests pass: 53 tests in total.tc:webandorca-ci-checks --no-typecheckpass, apart from the known localbuntooling error in its typecheck step.I manually tested these changes locally
Automated tests added/updated, or explained why not below
Notes
Renderer-only layout change. No settings, wire or platform impact. Paired web clients render the same component.