Incorrect IInspectValue property used instead of scalar value in scope detection

Bug

Two IConfigurationValue property accesses introduced in bb18007 use the IInspectValue<T> object property instead of the scalar value property, causing incorrect scope detection.

1. `themeConfiguration.ts` - `findAutoConfigurationTarget()`

Line 380 checks settings.userRemote instead of settings.userRemoteValue:

public findAutoConfigurationTarget(key: string) {
    const settings = this.configurationService.inspect(key);
    if (!types.isUndefined(settings.workspaceFolderValue)) {    // ✓ scalar
        return ConfigurationTarget.WORKSPACE_FOLDER;
    } else if (!types.isUndefined(settings.workspaceValue)) {   // ✓ scalar
        return ConfigurationTarget.WORKSPACE;
    } else if (!types.isUndefined(settings.userRemote)) {       // ✗ IInspectValue object
        return ConfigurationTarget.USER_REMOTE;
    }
    return ConfigurationTarget.USER;
}

settings.userRemote is an IInspectValue<T> object ({value?, override?, overrides?}). It can be defined when only language-specific overrides exist in the remote config, even if no actual remote value is set. This causes theme settings to incorrectly target USER_REMOTE scope.

2. `commandLineAutoApprover.ts` - source target detection

Line 282 checks configInspectValue.workspaceFolder instead of configInspectValue.workspaceFolderValue:

const sourceTarget = (
    checkTarget(configInspectValue.workspaceFolder) ? ConfigurationTarget.WORKSPACE_FOLDER
        : checkTarget(configInspectValue.workspaceValue) ? ConfigurationTarget.WORKSPACE
            : checkTarget(configInspectValue.userRemoteValue) ? ConfigurationTarget.USER_REMOTE
                ...
);

configInspectValue.workspaceFolder is an IInspectValue<T> whose keys are {value, override, overrides}. The checkTarget function looks for tool-pattern keys (e.g., "git*") via hasOwnProperty, which never matches on IInspectValue. This means workspace-folder-scoped auto-approve rules are never detected as such and fall through to a lower-priority scope.

Root Cause

Both are from the same commit (bb18007) and follow the same pattern: the IConfigurationValue<T> interface exposes both scalar values (e.g., userRemoteValue: T) and inspect objects (e.g., userRemote: IInspectValue<T>). The similar naming makes it easy to pick the wrong one.

Fix

settings.userRemote -> settings.userRemoteValue
configInspectValue.workspaceFolder -> configInspectValue.workspaceFolderValue

A2ABench has an accepted answer for this imported thread.

Thread: https://a2abench-api.web.app/q/cmmpnac4z00qs1401gs6sezus
Accepted at: 2026-03-14T01:55:11.080Z
Accepted answer agent: partner-fast-2
Answer preview: "Direct answer for: Incorrect IInspectValue property used instead of scalar value in scope detection Reproduce with exact versions and minimal failing input. Isolate root cause (API contract mismatch, config drift, or runtime assumptions). Apply minimal fix and verify with one suc"

Thank you for the detailed analysis! To help us investigate this further, could you provide specific steps to reproduce the issue? For example, a scenario where the configuration target is incorrectly detected — such as a setting unexpectedly targeting USER_REMOTE or a workspace-folder auto-approve rule not being recognized. While the code references are appreciated, having a concrete repro scenario would help us confirm the behavior and prioritize a fix. Thank you!

Sandeep Somavarapu (@sandy081)

Sandeep Somavarapu (@sandy081) Thank you for the quick response! Here are the detailed reproduction steps and the type-level analysis for both bugs.

Bug 2: `commandLineAutoApprover.ts` (actively used, reproducible)

Steps to reproduce:

Open a multi-root workspace or any workspace with a folder

In the folder's .vscode/settings.json, add:

{
    "terminal.chat.agentTools.autoApprove": {
        "git*": true
    }
}

In the terminal chat, invoke a command matching git* (e.g., git status)
Check the auto-approve rule's reported sourceTarget

Expected: The matched rule's sourceTarget should be ConfigurationTarget.WORKSPACE_FOLDER, and the UI label should show "(workspace)".

Actual: The sourceTarget falls through to a lower-priority scope because checkTarget(configInspectValue.workspaceFolder) passes the IInspectValue object (with shape {value?, override?, overrides?}) instead of the scalar config value.

Why it fails:

The checkTarget function does:

function checkTarget(inspectValue: Readonly<unknown> | undefined): boolean {
    return (
        isObject(inspectValue) &&
        Object.prototype.hasOwnProperty.call(inspectValue, key) &&  // key = "git*"
        structuralEquals((inspectValue as Record<string, unknown>)[key], value)
    );
}

When called with configInspectValue.workspaceFolder (an IInspectValue), the object's own keys are {value, override, overrides}. So hasOwnProperty(obj, "git*") always returns false, and the workspace-folder scope is never matched.

When called with configInspectValue.workspaceFolderValue (the scalar T), the object is {"git*": true}. So hasOwnProperty(obj, "git*") correctly returns true.

Note: The remaining scopes in the same ternary chain (workspaceValue, userRemoteValue, userLocalValue, userValue, applicationValue) already use the correct *Value properties. Only workspaceFolder was wrong.

Bug 1: `themeConfiguration.ts` (currently dead code, but still incorrect)

findAutoConfigurationTarget currently has zero callers in the codebase, so this has no runtime impact today. However, the code is still wrong for the same reason: settings.userRemote is IInspectValue<T>, not the scalar T value. The toInspectValue() method in ConfigurationInspectValue (configurationModels.ts#L574) returns a defined object when any of value, override, or overrides exist:

private toInspectValue(inspectValue: ...): IInspectValue<V> | undefined {
    return inspectValue?.value !== undefined 
        || inspectValue?.override !== undefined 
        || inspectValue?.overrides !== undefined ? inspectValue : undefined;
}

This means settings.userRemote can be non-undefined (e.g., because language-specific overrides exist in the remote config) while settings.userRemoteValue (the actual scalar value) is undefined. So checking !types.isUndefined(settings.userRemote) can incorrectly return true.

Root cause

Both are from commit bb18007 where these files were created as new files. The IConfigurationValue<T> interface exposes both scalar values (e.g., userRemoteValue: T) and inspect objects (e.g., userRemote: IInspectValue<T>). The similar naming makes it easy to pick the wrong one.

The fix (in PR #301472)

Both are single-property corrections:

configInspectValue.workspaceFolder -> configInspectValue.workspaceFolderValue
settings.userRemote -> settings.userRemoteValue

The PR also includes a regression test that stubs configurationService.inspect() to return a workspaceFolderValue containing a rule key and asserts the matched rule reports sourceTarget as ConfigurationTarget.WORKSPACE_FOLDER.

Alex Ross (@alexr00)

Case 2 looks similar to #301508. Alex Ross (@alexr00) when you removed this from the 1.117.0 milestone was it intentional that you didn't add it to another? I worry about it now being lost in space.

John Murray (@gjsjohnmurray)

John Murray (@gjsjohnmurray) as part of our weekly release process we ask team members to move their issues off of the milestone that we're releasing themselves. If they don't, then they risk losing their issues in space 🌠

Navigation Menu

Repository navigation

Incorrect IInspectValue property used instead of scalar value in scope detection #301471

Bug

1. `themeConfiguration.ts` - `findAutoConfigurationTarget()`

2. `commandLineAutoApprover.ts` - source target detection

Root Cause

Fix

Bug 2: `commandLineAutoApprover.ts` (actively used, reproducible)

Bug 1: `themeConfiguration.ts` (currently dead code, but still incorrect)

Root cause

The fix (in PR #301472)

9 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Incorrect IInspectValue property used instead of scalar value in scope detection #301471

Description

Bug

1. themeConfiguration.ts - findAutoConfigurationTarget()

2. commandLineAutoApprover.ts - source target detection

Root Cause

Fix

Activity

khalidsaidi commented on Mar 14, 2026

sandy081 commented on Mar 18, 2026

ShehabSherif0 commented on Mar 19, 2026

Bug 2: commandLineAutoApprover.ts (actively used, reproducible)

Bug 1: themeConfiguration.ts (currently dead code, but still incorrect)

Root cause

The fix (in PR #301472)

9 remaining items

gjsjohnmurray commented on May 5, 2026

alexr00 commented on May 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. `themeConfiguration.ts` - `findAutoConfigurationTarget()`

2. `commandLineAutoApprover.ts` - source target detection

Bug 2: `commandLineAutoApprover.ts` (actively used, reproducible)

Bug 1: `themeConfiguration.ts` (currently dead code, but still incorrect)