Change default permissions of CLI reading outside of workspace to false

[lambertjosh]

Context

Implementation

Changes default configuration file parameter for automatic approval of read operations across the full computer when using the CLI.

The reason is that I don't think most users understand when they install and try the CLI that it arrives with defaults that could cause more data than expected on the users drive to be sent to an LLM and potentially saved or exposed to third parties (like the LLM provider). I personally found this default disconcerting and surprising, and I imagine it could erode user trust in Kilo Code lead to unfortunate accidents. (For both Kilo and the user, as a result of trying to clean up)

Significant behavior change / change management

We need to be careful in rolling out this change, in whether it will impact users who have already been using the CLI for some time and may like the current behavior. It could be construed as a breaking change.

The ideal scenario would be that we change the default moving forward, while leaving current users with the behavior they have likely already gotten used to.

How to Test

Ask Kilo Code CLI to perform an action that would require reading a file outside of it's current directory it was called in. See if it prompts for approval first, if so, this change worked.

Get in Touch

[changeset-bot]

🦋 Changeset detected

Latest commit: ace16c2

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@kilocode/cli	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[lambertjosh]

Thoughts on this PR @RSO and who would be best to review it?

[RSO]

It makes sense to me, but I'd love a second opinion from @catrielmuller to be sure.

[catrielmuller]

@lambertjosh , please add a changeset entry with pnpm changeset on the root folder to bump the cli version and give you the credits for the change.

Significant behavior change / change management
We need to be careful in rolling out this change, in whether it will impact users who have already been using the CLI for some time and may like the current behavior. It could be construed as a breaking change.

The ideal scenario would be that we change the default moving forward, while leaving current users with the behavior they have likely already gotten used to.

@RSO the change it's not than big because only affect to the new users, the default values are used to generate the config.json so the existing user will be continue using the existing configuration that they have. (This will be not override the configuration of them)

[catrielmuller]

Please update the docs as well -> https://github.com/Kilo-Org/kilocode/blob/main/apps/kilocode-docs/docs/cli.md

[lambertjosh]

Please update the docs as well -> https://github.com/Kilo-Org/kilocode/blob/main/apps/kilocode-docs/docs/cli.md

@catrielmuller - thanks, good catch. I actually took the opportunity to try to re-organize the docs a bit to split out the auto-approval feature, and the two operational modes. Please let me know if you think this is clearer or not. Previously interactive mode was nested inside of autonomous mode.

[lambertjosh]

@lambertjosh , please add a changeset entry with pnpm changeset on the root folder to bump the cli version and give you the credits for the change.

@catrielmuller - I took a shot at adding a changeset, it's my first one so please take a careful look. 😉

Significant behavior change / change management
We need to be careful in rolling out this change, in whether it will impact users who have already been using the CLI for some time and may like the current behavior. It could be construed as a breaking change.
The ideal scenario would be that we change the default moving forward, while leaving current users with the behavior they have likely already gotten used to.

@RSO the change it's not than big because only affect to the new users, the default values are used to generate the config.json so the existing user will be continue using the existing configuration that they have. (This will be not override the configuration of them)

This is great. Just so I understand, upon installation the config.json file is written and on updates it is left alone. Is that an accurate understanding? This way, any changes to the default config.json in updates would not override existing user settings.

[lambertjosh]

@catrielmuller @RSO - I do wonder if by changing this default we will be too negatively impacting the UX for CI/CD or other use cases. They could update their pipelines to modify this line, but I also wonder if some CLI options to allow for overriding auto-approval settings may be worthwhile?

Other ideas here?

[lambertjosh]

@pandemicsyn - Can you also do a review to make sure this doesn't break Cloud Agents?

[pandemicsyn]

@pandemicsyn - Can you also do a review to make sure this doesn't break Cloud Agents?

Should be good to go! Cloud agent actually doesn't rely on auto creation of the config and already used outside: false.

[catrielmuller]

@lambertjosh , please add a changeset entry with pnpm changeset on the root folder to bump the cli version and give you the credits for the change.

@catrielmuller - I took a shot at adding a changeset, it's my first one so please take a careful look. 😉

Significant behavior change / change management
We need to be careful in rolling out this change, in whether it will impact users who have already been using the CLI for some time and may like the current behavior. It could be construed as a breaking change.
The ideal scenario would be that we change the default moving forward, while leaving current users with the behavior they have likely already gotten used to.

@RSO the change it's not than big because only affect to the new users, the default values are used to generate the config.json so the existing user will be continue using the existing configuration that they have. (This will be not override the configuration of them)

This is great. Just so I understand, upon installation the config.json file is written and on updates it is left alone. Is that an accurate understanding? This way, any changes to the default config.json in updates would not override existing user settings.

Yes, Existing user configurations are respected because the logic effectively merges the defaults with the user's specific config. If a user is missing a specific entry in their config.json, it falls back to the default (And update their config.json), but it won't overwrite their existing settings.

Think of the resolution strategy like this:

const finalConfig = {
  ...DEFAULT_CONFIG,
  ...userConfig
  ...ENV_VARS
};

[lambertjosh]

I still can't validate the entire CLI works as any model query seems to hang.

That said I renamed my existing config.json then re-run pnpm start config and validated that the new config now has reading outside of workspace defaulted to off:

...
      "kilocodeModel": "x-ai/grok-code-fast-1"
    }
  ],
  "autoApproval": {
    "enabled": true,
    "read": {
      "enabled": true,
      "outside": false
    },
    "write": {
...

[lambertjosh]

OK thanks to Christiaan's help I have the CLI running locally. I have validated that the CLI works and that the default is changed as expected.

[emilieschario]

I approve the decision

[kiloconnect]

✅ No Issues Found

4 files reviewed | Confidence: 95% | Recommendation: Merge

Review Details

Files:

• .changeset/every-knives-dig.md - Changeset for patch release
• apps/kilocode-docs/docs/cli.md - Documentation updated with new default
• cli/src/config/__tests__/auto-approval.test.ts - Test updated to match new default
• cli/src/config/defaults.ts - Default read.outside changed from true to false

Checked: Security, bugs, consistency, test coverage

Assessment:

• ✅ Security improvement: Follows principle of least privilege
• ✅ Code change is minimal and correct
• ✅ Test properly updated to match new default
• ✅ Documentation reflects the new behavior
• ✅ Changeset correctly marked as patch

[kiloconnect]

✅ No Issues Found

4 files reviewed | Confidence: 95% | Recommendation: Merge

Review Details

Files:

• .changeset/every-knives-dig.md - Changeset for patch release
• apps/kilocode-docs/docs/cli.md - Documentation updated with new default and restructured for clarity
• cli/src/config/__tests__/auto-approval.test.ts - Test updated to match new default
• cli/src/config/defaults.ts - Default read.outside changed from true to false

Checked: Security, bugs, consistency, test coverage

Assessment:

• ✅ Security improvement: Follows principle of least privilege by requiring explicit approval for reading files outside workspace
• ✅ Code change is minimal and correct
• ✅ Test properly updated to match new default
• ✅ Documentation reflects the new behavior
• ✅ Changeset correctly marked as patch

[lambertjosh]

Rebased and retested, still looks good:

[lambertjosh]

OK so I went further and tried to validate the CLI would actually prompt for approval, and it unfortunately does not.

With the help of AI looked into this, and it seems like the auto-approval settings are not passed to the extension, but rather the extension just uses the defaults. Here is the analysis:

Investigation Results: CLI Does NOT Block for Approval on Outside-Workspace Reads

Root Cause Identified

The CLI does not ask for approval before reading files outside the workspace because the extension's auto-approval settings default to true for outside-workspace reads, and the CLI never overrides these defaults.

Technical Details

1. Extension Default Behavior (src/core/webview/ClineProvider.ts:2257-2258)

alwaysAllowReadOnly: alwaysAllowReadOnly ?? true,
alwaysAllowReadOnlyOutsideWorkspace: alwaysAllowReadOnlyOutsideWorkspace ?? true,

The extension defaults alwaysAllowReadOnlyOutsideWorkspace to true when not explicitly set.

2. CLI Initial State (cli/src/host/ExtensionHost.ts:758-793)

The CLI's initializeState() method creates the initial extension state but does NOT include any auto-approval settings like:

• alwaysAllowReadOnly
• alwaysAllowReadOnlyOutsideWorkspace
• autoApprovalEnabled

3. CLI Config Mapping (cli/src/config/mapper.ts:32-39)

The mapConfigToExtensionState() function only maps:

• apiConfiguration
• currentApiConfigName
• listApiConfigMeta
• telemetrySetting
• mode

It does NOT map any auto-approval settings from the CLI config to the extension state.

4. Extension Auto-Approval Logic (src/core/auto-approval/index.ts:171-176)

if (isReadOnlyToolAction(tool)) {
    return state.alwaysAllowReadOnly === true &&
        (!isOutsideWorkspace || state.alwaysAllowReadOnlyOutsideWorkspace === true)
        ? { decision: "approve" }
        : { decision: "ask" }
}

Since alwaysAllowReadOnlyOutsideWorkspace defaults to true, outside-workspace reads are auto-approved.

The Flow

1. User runs CLI without --auto flag
2. CLI initializes extension state without auto-approval settings
3. Extension uses defaults: alwaysAllowReadOnlyOutsideWorkspace: true
4. When ReadFileTool runs, it sets isOutsideWorkspace: true for files outside workspace
5. Extension's checkAutoApproval() sees alwaysAllowReadOnlyOutsideWorkspace === true
6. Returns { decision: "approve" } - no blocking, no user prompt
7. CLI's useApprovalMonitor never gets a chance to intercept because the extension already auto-approved

The Fix

The CLI needs to inject its auto-approval configuration into the extension state. The CLI has its own config structure (autoApproval.read.outside) but never sends these values to the extension.

Required changes:

Update cli/src/config/mapper.ts to map CLI auto-approval settings to extension state:

return {
    ...currentState,
    // ... existing mappings ...
    alwaysAllowReadOnly: config.autoApproval?.read?.enabled ?? false,
    alwaysAllowReadOnlyOutsideWorkspace: config.autoApproval?.read?.outside ?? false,
    autoApprovalEnabled: config.autoApproval?.enabled ?? false,
    // ... other auto-approval settings
}

The CLI has all the approval decision logic in place (cli/src/services/approvalDecision.ts), but it's never used because the extension auto-approves before the CLI can intercept.

[lambertjosh]

OK, with #4535 fixing the settings passing issue, I think this isolated issue is ready to go. When I have both of these changes local, it works and checks for approval.