Skip to content

[Feat] Integrate DCG with command auto-approval and denial UX - #1062

Open
navedmerchant wants to merge 2 commits into
feat/dcg-settingfrom
feat/dcg-command-integration
Open

[Feat] Integrate DCG with command auto-approval and denial UX#1062
navedmerchant wants to merge 2 commits into
feat/dcg-settingfrom
feat/dcg-command-integration

Conversation

@navedmerchant

Copy link
Copy Markdown
Contributor

Related GitHub Issue

Closes #1058
Completes #1049. Split from #1050.

Description

Completes the feature at the command approval boundary. DCG-approved commands can bypass the legacy allowlist only when command auto-approval and DCG are enabled. DCG-blocked commands are protected and require explicit approval. Disabling DCG preserves existing behavior. Localized reason/rule feedback and a dedicated denied-command chat state are included.

A user can still explicitly approve a DCG-blocked command; denying it does not execute it.

Stack

4 / 4 — base: feat/dcg-setting

The complete stack tip is tree-identical to the original #1050 branch, so no original change was dropped.

Test Procedure

pnpm --dir src exec vitest run core/auto-approval/__tests__/dcg.spec.ts core/tools/__tests__/executeCommandTool.spec.ts
pnpm --dir packages/types exec vitest run src/__tests__/message.test.ts
pnpm --dir webview-ui exec vitest run src/components/chat/__tests__/ChatRow.command-denied.spec.tsx src/components/chat/__tests__/CommandExecution.spec.tsx
pnpm --dir packages/types check-types
pnpm --dir src check-types
pnpm --dir webview-ui check-types
pnpm --dir src bundle
pnpm --dir webview-ui build

Result: 41 extension, 7 type-package, and 40 webview tests passed; type-checks, production builds, lint, pre-push checks, and i18n validation passed.

Checklist

  • Safety boundary covered by tests
  • DCG-disabled behavior preserved
  • Denied UX and localization included
  • Type-check/build/lint passing

@navedmerchant navedmerchant added the enhancement New feature or request label Jul 30, 2026
@navedmerchant navedmerchant added the enhancement New feature or request label Jul 30, 2026
@navedmerchant navedmerchant self-assigned this Jul 30, 2026
@coderabbitai

coderabbitai Bot commented Jul 30, 2026

Copy link
Copy Markdown
Contributor

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 11139ba5-dab2-488d-96ec-3800cdecbf97

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

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

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

@codecov

codecov Bot commented Jul 30, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 86.48649% with 5 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
src/core/tools/ExecuteCommandTool.ts 83.33% 2 Missing and 2 partials ⚠️
src/core/task/Task.ts 50.00% 1 Missing ⚠️

📢 Thoughts on this report? Let us know!

@github-actions github-actions Bot added the awaiting-review PR changes are ready and waiting for maintainer re-review label Jul 30, 2026
@navedmerchant
navedmerchant force-pushed the feat/dcg-command-integration branch from 3e1b109 to 5f6e0a8 Compare July 30, 2026 04:50
@github-actions github-actions Bot added awaiting-review PR changes are ready and waiting for maintainer re-review and removed awaiting-review PR changes are ready and waiting for maintainer re-review labels Jul 30, 2026

@edelauna edelauna left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some minor questions

Comment thread src/core/auto-approval/__tests__/dcg.spec.ts
Comment thread src/core/auto-approval/index.ts
@github-actions github-actions Bot added awaiting-author PR is waiting for the author to address requested changes and removed awaiting-review PR changes are ready and waiting for maintainer re-review labels Jul 31, 2026
@navedmerchant
navedmerchant force-pushed the feat/dcg-command-integration branch from 5f6e0a8 to dd00d03 Compare August 1, 2026 17:23
@github-actions github-actions Bot removed the awaiting-author PR is waiting for the author to address requested changes label Aug 1, 2026
@navedmerchant
navedmerchant force-pushed the feat/dcg-command-integration branch from dd00d03 to e996b73 Compare August 1, 2026 17:30
@github-actions github-actions Bot added the awaiting-author PR is waiting for the author to address requested changes label Aug 1, 2026

@edelauna edelauna left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Had some comments related to implementation.

let dcgBlocked = false
if (providerState?.destructiveCommandGuardEnabled === true) {
const { ensureDcgInstalled, runDcg } = await import("../../services/destructive-command-guard")
if (!provider) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this guard ever fire? provider is obtained at line 134 via providerRef.deref(), then used with optional chaining: provider?.getState(). So providerState?.destructiveCommandGuardEnabled === true is only true when provider is non-null — meaning we can only enter this block when provider is already guaranteed non-null. If provider is null, the outer if is false and we skip DCG entirely, silently bypassing it rather than throwing.


const didApprove = await askApproval("command", canonicalCommand)
const provider = await task.providerRef.deref()
const providerState = await provider?.getState()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This moves getState() from post-approval to pre-approval, so it now runs for every command — including when DCG is disabled (the common case) and for commands the user declines. Is there a cheaper way to read just destructiveCommandGuardEnabled before deciding whether to invoke the full state?

})

expect(mockEnsureDcgInstalled).toHaveBeenCalledWith("/test/storage")
expect(mockRunDcg).toHaveBeenCalledWith("/test/storage/dcg", "echo test", "/test/workspace")

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This confirms DCG was invoked correctly, but does it verify the allow result was acted upon? mockRunDcg defaults to { decision: "allow" }, so a mutation that ignores dcgResult.decision and always calls askApproval without isProtected would still pass both of these assertions.

expect(screen.queryByText("chat:commandExecution.denied")).not.toBeInTheDocument()
expect(screen.getByTestId("command-execution")).toHaveAttribute("data-denied", "false")
})
})

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The two cases cover "deny" and "approve", but not autoApprovalDecision: undefined — the normal state for commands awaiting user input. A mutation of === "deny" to !== "approve" in ChatRow.tsx would make those render as denied without being caught. Worth a third renderCommand(undefined) case?

case "mistake_limit_reached":
return [null, null] // These will be handled by ErrorRow component
case "command":
if (message.autoApprovalDecision === "deny") {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When DCG is enabled, can autoApprovalDecision ever be "deny" here? checkAutoApproval short-circuits to approve before reaching getCommandDecision when DCG is on, so this branch looks like it only fires via the legacy denylist (DCG disabled). Is that the intent, or should DCG blocks also show this denied state?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting-author PR is waiting for the author to address requested changes enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants