feat(ai-terminal): add shell command whitelist for auto-approval by eneufeld · Pull Request #16931 · eclipse-theia/theia

eneufeld · 2026-02-03T17:25:40Z

What it does

Adds command-level analysis and pattern-based whitelist for the shellExecute tool, allowing users to auto-approve specific commands while requiring confirmation for others.

Key features:

Pattern-based whitelist with word-boundary prefix matching
Commands with dangerous patterns ($() or backticks) are never auto-approved
Concatenated commands (&&, ||, ;, |) require ALL sub-commands to match
UI section in AI Configuration → Tools tab for managing patterns
Patterns persist via preferences

Additional changes:

Introduces shouldAutoApprove hook on ToolRequest interface, allowing tools to control their own auto-approval logic without hardcoding tool IDs in the chat service.
Adds ShellCommandAnalyzer for parsing shell commands and detecting dangerous patterns like command substitution.
Adds ShellCommandWhitelistService for managing whitelist patterns with word-boundary prefix matching (e.g., "git log" matches "git log --oneline" but not "git logger" or "sudo git log").
Empty or whitespace-only patterns are rejected to prevent accidental match-all configurations.

How to test

Set shellExecute to Confirm. Then add 2 commands that should be auto-approved. then ask the shell execute to execute those. alone, combined and combined with not approved tools.

Follow-ups

Breaking changes

This PR introduces breaking changes and requires careful review. If yes, the breaking changes section in the changelog has been updated.

Attribution

Review checklist

As an author, I have thoroughly tested my changes and carefully followed the review guidelines
User-facing text is internationalized using the nls service (for details, please see the Internationalization/Localization section in the Coding Guidelines)

Reminder for reviewers

As a reviewer, I agree to behave in accordance with the review guidelines

Adds command-level analysis and pattern-based whitelist for the shellExecute tool, allowing users to auto-approve specific commands while requiring confirmation for others. Key features: - Pattern-based whitelist with word-boundary prefix matching - Commands with dangerous patterns ($() or backticks) are never auto-approved - Concatenated commands (&&, ||, ;, |) require ALL sub-commands to match - UI section in AI Configuration → Tools tab for managing patterns - Patterns persist via preferences Additional changes: - Introduces shouldAutoApprove hook on ToolRequest interface, allowing tools to control their own auto-approval logic without hardcoding tool IDs in the chat service. - Adds ShellCommandAnalyzer for parsing shell commands and detecting dangerous patterns like command substitution. - Adds ShellCommandWhitelistService for managing whitelist patterns with word-boundary prefix matching (e.g., "git log" matches "git log --oneline" but not "git logger" or "sudo git log"). - Empty or whitespace-only patterns are rejected to prevent accidental match-all configurations.

sdirix

Thanks for the PR. I can confirm that the whitelist works for me.

Besides some details for code location and parsing, the main drawback of this PR is that it does not touch the confirmation UI of the shell execution. If the user knows about this whitelisting possibility, then they don't really know anymore what the buttons in the UI are doing.

I think we need to fully customize the behavior in the UI and make it explicit, e.g. when the LLM generates git log --oneline this are all the possible actions we can take:

Deny

Deny
Deny with reason
Always deny (git log) for this workspace
Always deny (git log) for user
Always deny (git log *) for this workspace
Always deny (git log *) for user

Approve

Approve
Approve and whitelist (git log) for this workspace
Approve and whitelist (git log) for user
Approve and whitelist (git log *) for this workspace
Approve and whitelist (git log *) for user

Claude Code supports all of these actions, however by default in the TUI they only expose

Approve
Approve and whitelist (git log *) for this workspace
Deny [optional reason]

The other options can be reached by editing the claude settings files or using /permissions within Claude Code.

Because we have a graphical UI I think we could even try to offer all these options, via the dropdowns. By default we should highlight Deny, Deny with reason, Approve and Approve and whitelist (git log *) for this workspace.

Note if a local approve or deny list exists, then the global options have no effect anymore (unless we want to merge settings), so we should not offer them anymore.

Or we implement local <-> global merging, then I guess we would need to check all patterns registered local and global. First we should check whether a command is allowed/denied locally and only if there is no decision then we check for allowed/denied globally.

I would be fine with doing this UI adaptation in a follow up as long as you, I or someone else does it before the next release is done.

sdirix · 2026-02-03T17:32:05Z

packages/ai-chat/src/common/chat-tool-preferences.ts

 }

 export const TOOL_CONFIRMATION_PREFERENCE = 'ai-features.chat.toolConfirmation';
+export const SHELL_COMMAND_WHITELIST_PREFERENCE = 'ai-features.chat.shellCommandWhitelist';


I think this preference should be placed in the same package as the terminal tool itself.

sdirix · 2026-02-04T15:20:26Z

packages/ai-ide/src/browser/ai-configuration/tools-configuration-widget.tsx

+                <p className="ai-shell-whitelist-description">
+                    {nls.localize(
+                        'theia/ai/ide/toolsConfiguration/shellWhitelist/description',
+                        'Commands matching these patterns will be automatically allowed without confirmation. ' +


Commands matching these patterns will be automatically allowed without confirmation

I would prefer using the same syntax as Claude Code, e.g.

git log --> matches just git log git log * --> matches all possible parameters of git log

If we align with Claude Code then it will be trivial to sync/copy/import their settings to/from Theia and users don't need to know two different syntaxes (besides the Bash()) part which I would not add here

Edit: Note that Claude Code also supports this weird git log: * syntax. So I guess at least for importing we would need to be able to handle that.

from claude docs: The space before * matters: Bash(ls ) matches ls -la but not lsof, while Bash(ls) matches both. The legacy :* suffix syntax is equivalent to * but is deprecated.

Yeah, they have weird syntax. But still ls will not match ls -a. So at least we should align on * usage.

yes on it ;-)

sdirix · 2026-02-04T15:23:44Z

packages/ai-terminal/src/common/shell-command-analyzer.ts

+/**
+ * Pattern to detect dangerous command substitution: $( or backticks
+ */
+const DANGEROUS_PATTERN = /\$\(|`/;


I think that there are more patterns like process substitutions or expansions. Maybe we also need to handle subshells?

sdirix · 2026-02-04T15:26:13Z

packages/ai-terminal/src/common/shell-command-analyzer.ts

+export function containsDangerousPatterns(command: string): boolean {
+    return DANGEROUS_PATTERN.test(command);
+}
+
+/**
+ * Parses a shell command string into individual sub-commands by splitting
+ * on concatenation operators (&&, ||, ;, |).
+ *
+ * @param command The shell command to parse
+ * @returns Array of trimmed sub-commands with empty entries filtered out
+ */
+export function parseCommand(command: string): string[] {
+    return command
+        .split(COMMAND_SEPARATOR_PATTERN)
+        .map(cmd => cmd.trim())
+        .filter(cmd => cmd.length > 0);
+}


Would be nicer to make them part of an injectable class so they can be easily overwritten by adopters

sdirix · 2026-02-04T15:32:14Z

packages/ai-terminal/src/common/shell-command-analyzer.ts

+ */
+const DANGEROUS_PATTERN = /\$\(|`/;
+
+/**


In general we could differentiate between dangerous, complex and simple commands. The command separation and whitelist matching should only be done on simple ones, to make sure we don't let something bad through.

It's the same in Claude Code. When the LLM generates a correct, non-dangerous command but it's too complex then it does not match to whitelists and does not offer to add it to whitelist.

sdirix · 2026-02-04T15:34:35Z

packages/ai-ide/src/browser/ai-configuration/tools-configuration-widget.tsx

+
+    protected handlePatternInputChange(value: string): void {
+        this.newPatternInput = value;
+        this.update();


In Theia we usually use uncontrolled inputs to avoid updating the widget for every keystroke

sdirix · 2026-02-04T15:51:14Z

packages/ai-terminal/src/browser/shell-command-whitelist-service.ts

+     * Returns false if the command contains dangerous patterns or if the whitelist is empty.
+     * Returns true only if ALL sub-commands match at least one whitelist pattern.
+     */
+    isCommandAllowed(command: string): boolean {


I think we should also support a blacklist of never allowed commands to avoid showing a UI for them and blocking the agent, e.g. never allow git push

github-project-automation bot added this to PR Backlog Feb 3, 2026

github-project-automation bot moved this to Waiting on reviewers in PR Backlog Feb 3, 2026

eneufeld requested a review from sdirix February 3, 2026 17:25

fix tsconfog

0dd3b6b

sdirix requested changes Feb 4, 2026

View reviewed changes

github-project-automation bot moved this from Waiting on reviewers to Waiting on author in PR Backlog Feb 4, 2026

eneufeld added 3 commits February 5, 2026 13:29

first round of review fixes

aaee262

support wildcards and claude syntax

1bae6a4

add blacklisting

89948dd

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(ai-terminal): add shell command whitelist for auto-approval#16931

feat(ai-terminal): add shell command whitelist for auto-approval#16931
eneufeld wants to merge 5 commits intomasterfrom
feat/shell-command-whitelist

eneufeld commented Feb 3, 2026

Uh oh!

sdirix left a comment •

edited

Loading

Uh oh!

sdirix Feb 3, 2026

Uh oh!

sdirix Feb 4, 2026 •

edited

Loading

Uh oh!

eneufeld Feb 5, 2026

Uh oh!

sdirix Feb 5, 2026

Uh oh!

eneufeld Feb 5, 2026

Uh oh!

sdirix Feb 4, 2026

Uh oh!

sdirix Feb 4, 2026

Uh oh!

sdirix Feb 4, 2026

Uh oh!

sdirix Feb 4, 2026

Uh oh!

sdirix Feb 4, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

eneufeld commented Feb 3, 2026

What it does

How to test

Follow-ups

Breaking changes

Attribution

Review checklist

Reminder for reviewers

Uh oh!

sdirix left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sdirix Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

sdirix left a comment •

edited

Loading

sdirix Feb 4, 2026 •

edited

Loading