Add configurable default access mode for new threads

[JustMarkDev]

What Changed

Added a persisted defaultRuntimeMode client setting and exposed it in apps/web settings UI as Default access. New draft threads now initialize with that setting instead of always starting in full-access.

Also updated the relevant settings and persistence tests to cover the new field.

Why

This makes the app remember the user’s preferred permission mode for new threads, so they do not have to reselect it every time. The change is scoped to client-side defaults and preserves existing behavior for saved data by falling back to the current full-access default when the new setting is absent.

UI Changes

Progetto.senza.titolo.mp4

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Closes #2662

---

Note

Low Risk
Client-side default for new draft permission mode only; schema defaults preserve prior behavior when the field is absent.

Overview
Adds a persisted defaultRuntimeMode server setting (defaulting to the existing full-access constant when unset) and a Default access control in settings so users can choose Supervised, Auto-accept edits, or Full access for new draft threads.

New drafts no longer hardcode DEFAULT_RUNTIME_MODE: buildNewDraftExecutionDefaults sets runtimeMode from the setting and keeps the provider default interaction mode; ChatView, useHandleNewThread, and the active composer fallback read settings.defaultRuntimeMode instead of the constant. Restore-to-defaults and the changed-settings list include the new field; server settings persistence tests cover round-tripping.

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

Note

Add configurable default access mode for new threads in server settings and UI

• Adds defaultRuntimeMode to ServerSettings and ServerSettingsPatch schemas in settings.ts, defaulting to DEFAULT_RUNTIME_MODE.
• Introduces buildNewDraftExecutionDefaults in chatThreadActions.ts to initialize new draft threads with runtimeMode from the configured default and interactionMode from the provider default.
• Updates ChatView.tsx and useHandleNewThread.ts to use settings.defaultRuntimeMode instead of the hardcoded DEFAULT_RUNTIME_MODE constant.
• Adds a 'Default access' select control in SettingsPanels.tsx so users can view, change, and reset the default runtime mode; restore-to-defaults also resets this field.

^{Macroscope summarized ea95e48.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: ec51989d-445f-46ca-a83b-27056716c368

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[macroscopeapp]

Approvability

Verdict: Needs human review

Introduces a new user-facing settings option that controls the default access mode for new threads. New features adding configuration capabilities warrant human review even when implementation is straightforward.

^{You can customize Macroscope's approvability policy. Learn more.}

Dismissing prior approval to re-evaluate 4642fd2

[juliusmarminge]

should be server setting imo

[JustMarkDev]

Sorry for the late response. I’ve fixed the merge conflicts, and the preference is now stored as a server setting.

[benglewis]

@juliusmarminge Honestly, I'm trying to make sense of this:

1. Why do you trust LLMs with full access to your machines? What if the agent just casually deletes your entire disk? Or it casually sends your credentials to various websites out to the world for others to use. Prompt injection in LLMs still exists and is not entirely preventable at this stage AFAIK, so this is like using software from some random supplier who you are not sure has protection against SQL injection and then giving them all of your computer user and all of its current permissions. What makes you feel safe / comfortable doing that?
2. Given this is the default behaviour, do you really have a good reason not to merge this PR allowing others to change their default setting when using T3 Code? This is the number 1 reason that I cannot realistically use T3 Code right now

[JustMarkDev]

I created this pr because I thought it would be a simple change to implement while learning agenting engineering (I read the code of course), I actually wouldn't be that affected by this change since I usually always run as always-approve, models are quite good at avoiding critical errors like eliminating a codebase, i've seen a couple of tweets of it happening but nothing a bit of better prompting or context management wouldn't fix. Also and I think this is the biggest reason as to why he's not merging: they are focused on other things, the new sidebar and mobile support (t3 cloud) and also i'm not a vouched contributor (not that I wanna be)