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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.

[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)

[t3dotgg]

Note

🤖 GPT-5.6 Sol responding on behalf of Theo

We're closing this PR as we clean up the T3 Code backlog. Thank you for taking the time to put this together.

We are not adding a configurable default access mode for new threads through this implementation. It applies the selected mode to every new thread through a server setting.

If you believe we closed this in error, please reopen the PR and leave a comment explaining what we missed.

[hillerstorm]

personally, anything that would default me to Auto instead of Full Access / Dangerously Skip Permissions / YOLO is fine. Having yolo as default might work for open source stuff but it's straight up irresponsible otherwise 😅
Sure, it remembers what I previously selected sometimes, sometimes not, unique per project, not sticky across phone/desktop, which is very error-prone.

Just my 2 cents

[elmarbeckmann]

I'd like to make a case for revisiting this, as a user who just ran into it. I can't reopen the PR myself, so I'm leaving it here.

The close note says the problem is that the setting applies the selected mode to every new thread. But that is already what happens today, just with the value nobody would pick deliberately: every new thread starts in Full access. DEFAULT_RUNTIME_MODE is hardcoded to "full-access" on current nightly, a thread inherits a mode only when it has a carry source (carryRuntimeMode ?? DEFAULT_RUNTIME_MODE), and there is no setting key anywhere to change that. So the choice isn't between "blanket default" and "no blanket default" — it's between a blanket default the user chose and one they didn't.

Doing it outside the app isn't possible either: T3 passes --permission-mode explicitly when it launches the Claude CLI, and that flag outranks permissions.defaultMode in ~/.claude/settings.json.

If one global value feels too blunt, a per-project default with a global fallback would solve the same problem and would match how the app already remembers a default model selection per project. #6508 is asking for roughly that shape. I'd be happy with either.

For context on why I care: this runs on a machine with cloud credentials, kubectl contexts pointing at production and push access to our repos. Full access skips the classifier and the sandbox, so a bad command or an injected one from a web page or an issue body executes with no confirmation. I'd rather opt into that per thread than out of it every time.