@tencent-ai/codebuddy-code 2.105.0 → 2.105.1

package/dist/web-ui/docs/en/cli/permissions.md

@@ -1,25 +1,25 @@
-# Permission Rules (Permissions)
+# Permission Rules
 
 > Precisely constrain what CodeBuddy Code can do with fine-grained allow / ask / deny rules, Permission Modes, and layered settings. Rules can be committed to the repository and shared with the team, or overridden locally by developers.
 
 ## Permission System Overview
 
-CodeBuddy Code uses a layered evaluation mechanism to balance capability and security. Before the main agent executes any tool call, it passes through the permission service (`tool-permission-service.ts::checkToolPermission`). Eight phases are evaluated in order:
+CodeBuddy Code uses a layered evaluation mechanism to balance capability and security. Before each tool call, the following eight phases are evaluated in order:
 
 | Phase | Check | Behavior on match |
 | :---- | :---- | :---------------- |
 | 1 | **Deny rules** | Reject immediately, with the highest priority |
 | 2 | **Trusted Allow rules** (user / cli / flag / session / policy / project under a trusted directory / `--allowedTools`) | Allow immediately, and **can bypass command safety checks** |
-| 3 | **Command safety check** (`checkCommandSafety`, interactive only) | Force confirmation for high-risk / dangerous commands |
+| 3 | **Command safety check** (interactive only) | Force confirmation for high-risk / dangerous commands |
 | 4 | **Ask rules** | Force confirmation |
 | 5 | **Bypass mode short-circuit** | Allow directly in `bypassPermissions` mode; downgrade to default when `disableBypassPermissionsMode` is enabled |
 | 6 | **Untrusted Allow rules** (project / local outside trusted directories, plus command / sandbox sources) | Allow, but **cannot bypass command safety checks** |
-| 7 | **Permission Mode strategy** (`tool-permission-strategy.ts`) | Decide whether approval is required based on the current [PermissionMode](permission-modes.md) |
+| 7 | **Permission Mode strategy** | Decide whether approval is required based on the current [Permission Mode](permission-modes.md) |
 | 8 | dontAsk / async agent fallback | Convert `ask` to `deny` in print / async agent scenarios to avoid deadlock |
 
-> **Key point**: deny always takes precedence, and allow is split into two layers: "trusted" and "untrusted". Before the project root is listed as a trusted directory, allow rules in `.codebuddy/settings.json` **cannot bypass the command safety gate**. This differs from cc and is designed to prevent malicious repositories from bypassing local safety protections by pushing their own settings into team PRs.
+> **Key point**: deny always takes precedence, and allow is split into two layers: "trusted" and "untrusted". Before the project root is listed as a trusted directory, allow rules in `.codebuddy/settings.json` **cannot bypass the command safety gate**. This is designed to prevent malicious repositories from bypassing local safety protections by pushing their own settings into team PRs.
 
-Read-only tools (Read / Grep / Glob, etc.) do not prompt for approval by default inside trusted directories. Editing tools and Bash always go through the full phase chain. See `tool-permission-strategy.ts::ToolPermissionDefaultStrategy` and `permission-utils.ts::isArgsInTrustedDirectories` for details.
+Read-only tools (Read / Grep / Glob, etc.) do not prompt for approval by default inside trusted directories. Editing tools and Bash always go through the full phase chain.
 
 ## Three Rule Behaviors
 
@@ -43,7 +43,7 @@ The three arrays under the `permissions` object correspond to three behaviors:
 
 ### `/permissions` command
 
-Enter `/permissions` in a session to open the permission management panel (implemented in `permissions-command-executor.ts`). You can view all current allow / ask / deny rules, which settings layer they come from, and temporarily add or remove them (written to the user, project, or project-local scope).
+Enter `/permissions` in a session to open the permission management panel. You can view all current allow / ask / deny rules, which settings layer they come from, and temporarily add or remove them (written to the user, project, or project-local scope).
 
 When **"Yes, don't ask again"** is selected in the dialog, CodeBuddy writes the most stable prefix for the current command into the `allow` array of the corresponding scope's settings.
 
@@ -56,8 +56,6 @@ When **"Yes, don't ask again"** is selected in the dialog, CodeBuddy writes the
 | `--add-dir <path>` | Add an extra directory to the trusted directory scope (affects whether Read requires confirmation) |
 | `-y` / `--dangerously-skip-permissions` | Equivalent to `--permission-mode bypassPermissions` |
 
-Definitions are in `cli-provider.ts:40-55`.
-
 ### Configuration Files
 
 See [Settings Configuration](settings.md) for details. CodeBuddy merges these four scopes:
@@ -69,8 +67,6 @@ See [Settings Configuration](settings.md) for details. CodeBuddy merges these fo
 | project-local | `<repo>/.codebuddy/settings.local.json` (not committed to git, local override) |
 | cliArg / flagSettings / session / policySettings | Process state, not persisted to disk |
 
-See `tool-permission-service.ts:647-741` for the merge implementation.
-
 ## Rule Syntax
 
 Rule form: `Tool` or `Tool(specifier)`.
@@ -86,7 +82,7 @@ Remove the parentheses to match all calls to a tool:
 | `Read` | All file reads |
 | `Edit` | All file edits |
 
-`*` can also be used as a standalone rule (`permission-utils.ts:194` treats it as a full-match wildcard).
+`*` can also be used as a standalone rule, equivalent to a full-match wildcard.
 
 ### Add a Specifier for Fine-Grained Matching
 
@@ -108,22 +104,22 @@ Write arguments inside the parentheses:
 
 ### Bash
 
-Bash rules support three syntax forms (implemented in `permission-utils.ts::matchSingleCommandAgainstPattern`, lines `414-450`):
+Bash rules support three syntax forms:
 
 | Syntax | Meaning | Example |
 | :----- | :------ | :------ |
 | Exact match | The pattern is exactly equal to the command | `Bash(npm run build)` only matches `npm run build` |
 | `:*` prefix | The pattern ends with `:*` → matches the first word / multi-word prefix of the command | `Bash(git:*)` matches `git status` / `git push origin main` |
-| Wildcard | When the pattern contains `*`, use picomatch bash mode (**`*` can cross `/`**) | `Bash(npm run *)` matches `npm run build`; `Bash(ls *)` matches `ls -al /tmp/x` |
+| Wildcard | When the pattern contains `*`, matches as a bash glob pattern (**`*` can cross `/`**) | `Bash(npm run *)` matches `npm run build`; `Bash(ls *)` matches `ls -al /tmp/x` |
 
-> Unlike minimatch, cbc deliberately enables `bash: true` for Bash wildcard mode so that `*` can cross `/`. Otherwise, `ls *` could not match `ls -al /xxx`, which is one of the most common pitfalls for users (see the comments in `permission-utils.ts:441-446`).
+> The wildcard mode deliberately lets `*` cross `/`. Otherwise, `ls *` could not match `ls -al /xxx`, which is one of the most common pitfalls for users.
 
 #### Compound Commands
 
-CodeBuddy uses `CommandParserService` (priority: tree-sitter > shell-quote > regex fallback; see `permission-utils.ts:357-378`) to parse shell operators `&&` / `||` / `;` / `|`, and evaluates each subcommand independently:
+CodeBuddy parses shell operators `&&` / `||` / `;` / `|` and evaluates each subcommand independently:
 
-- **deny / ask rules**: trigger if any subcommand matches (`matchCommandRule`, lines `305-334`)
-- **allow rules**: require **all subcommands to match** before allowing (`isCommandAllowed`, lines `478-500`). This is a different trade-off from cc: a compound command with one matching and one non-matching subcommand will still ask for approval, preventing attackers from hiding dangerous commands next to allowed ones
+- **deny / ask rules**: trigger if any subcommand matches
+- **allow rules**: require **all subcommands to match** before allowing — a compound command with one matching and one non-matching subcommand will still ask for approval, preventing attackers from hiding dangerous commands next to allowed ones
 
 Example:
 
@@ -137,11 +133,11 @@ git status; rm *   → ask (same as above)
 
 #### Redirection
 
-Commands containing `>` / `<` / `>>` / `<<` / `&>` require an **exact match** under allow rules (`permission-utils.ts:482-485`); wildcard rules do not apply.
+Commands containing `>` / `<` / `>>` / `<<` / `&>` require an **exact match** under allow rules; wildcard rules do not apply.
 
 ### Read / Edit / Write
 
-File rules use `minimatch` for glob matching and perform three layers of path normalization (`permission-utils.ts::matchFileRule` and `normalizePath`, lines `241-268`):
+File rules use glob matching and perform three layers of path normalization:
 
 | pattern | Explanation | Example |
 | :------ | :---------- | :------ |
@@ -150,12 +146,12 @@ File rules use `minimatch` for glob matching and perform three layers of path no
 | `/path` | Starting from the project root | `Edit(/src/**/*.ts)` |
 | `path` or `./path` | Starting from the current working directory | `Read(.env)` |
 
-Matching options: `dot: true` (allow dotfiles), `nocase: true` (case-insensitive), `matchBase: true` (bare filenames can match at any depth).
+Matching options: dotfiles allowed, case-insensitive, bare filenames can match at any depth.
 
 Notes:
 
 - deny rules such as `Edit(.git/**)` block all attempts through Edit / Write / NotebookEdit, but **do not block** indirect paths through Bash such as `python -c 'open(".git/config", "w")...'`. OS-level protection depends on [Bash sandboxing](bash-sandboxing.md)
-- Read rules are also intercepted and parsed for some Bash file-read commands (`cat`, `head`, `tail`, etc.; see the special handling for these commands inside `command-utils.ts::checkCommandSafety`)
+- Read rules are also intercepted and parsed for some Bash file-read commands (`cat`, `head`, `tail`, etc.)
 
 ### WebFetch
 
@@ -164,7 +160,7 @@ WebFetch                       # any URL
 WebFetch(domain:example.com)   # only example.com and its subdomains
 ```
 
-The matching implementation is in `permission-utils.ts::matchURLRule` (line `515`) and supports the `domain:` prefix for hostname matching.
+Supports the `domain:` prefix for hostname matching (including subdomains).
 
 ### MCP Tools
 
@@ -176,7 +172,7 @@ MCP tools are named in the format `mcp__<server>__<tool>`. Rules support three g
 | `mcp__puppeteer__*` | Same as above (wildcard form) |
 | `mcp__puppeteer__navigate` | Only the navigate tool |
 
-Starting from `tool-permission-service.ts:152`, the code checks `tool.name.startsWith('mcp__')` and enters the MCP-specific branch.
+Tool names starting with `mcp__` are matched as MCP rules.
 
 ### Agent (Subagent)
 
@@ -206,7 +202,7 @@ After being denied, that `subagent_type` will be rejected when the main agent in
 }
 ```
 
-Skill rules **must** be exact matches (`permission-utils.ts::matchSkillRule`, lines `458-464`); wildcards are not supported.
+Skill rules **must** be exact matches; wildcards are not supported.
 
 ## Trusted Directories
 
@@ -221,22 +217,22 @@ Several ways to expand the trusted scope:
 | `permissions.additionalDirectories` setting | Persistent |
 | `permissions.trustedDirectories` setting | Persistent |
 
-Implementation: `permission-utils.ts:561-583`. Trusted directory list = `workspace root + settings.trustedDirectories + session.options.addDir`.
+The effective trusted directory list = workspace root + `settings.trustedDirectories` + directories added at startup with `--add-dir` or in-session with `/add-dir`.
 
-> Both `--add-dir` and `permissions.additionalDirectories` only grant **file access**. They **do not** make CodeBuddy load `.codebuddy/` configuration from those directories (agents / hooks / settings, etc. still use the startup directory). This matches cc behavior.
+> Both `--add-dir` and `permissions.additionalDirectories` only grant **file access**. They **do not** make CodeBuddy load `.codebuddy/` configuration from those directories (agents / hooks / settings, etc. still use the startup directory).
 
 ### Project Directory Trust Switch
 
-Whether you have "explicitly trusted" a repository directory also affects the trust level of allow rules (`tool-permission-service.ts:182`). When the directory is **not trusted**:
+Whether you have "explicitly trusted" a repository directory also affects the trust level of allow rules. When the directory is **not trusted**:
 
 - `allow` rules in `<repo>/.codebuddy/settings.json` and `.codebuddy/settings.local.json` are classified into the **untrusted** layer (Phase 6), and **cannot** bypass command safety checks
-- After the user confirms trust in the interactive UI (`directoryTrustService.isTrustDirectory`), project-level rules are promoted to the Phase 2 trusted layer
+- After the user confirms trust in the interactive UI, project-level rules are promoted to the Phase 2 trusted layer
 
-This is a cbc-specific security model designed to reduce lateral risk that can arise immediately after cloning and running a repository.
+This is designed to reduce lateral risk that can arise immediately after cloning and running a repository.
 
 ## Protected Files / Paths
 
-In any mode, CodeBuddy adds extra protection for a set of critical paths (overlapping with the [PermissionMode documentation](permission-modes.md#protected-critical-files)):
+In any mode, CodeBuddy adds extra protection for a set of critical paths (matching [Permission Modes](permission-modes.md#protected-critical-files)):
 
 - The repository itself: `.git`, `.gitconfig`, `.gitmodules`
 - Shell configuration: `.bashrc` / `.zshrc` / `.envrc`, etc.
@@ -245,7 +241,7 @@ In any mode, CodeBuddy adds extra protection for a set of critical paths (overla
 - CodeBuddy itself: `.codebuddy` (except `.codebuddy/worktrees`)
 - MCP / configuration: `.mcp.json` / `.codebuddy.json`
 
-`bypassPermissions` mode still allows most of these through, but "catastrophic commands" such as `rm -rf /` / `rm -rf ~` are forced to ask through the `isDangerousCommand` fallback (`tool-permission-service.ts:244`).
+`bypassPermissions` mode still allows most of these through, but "catastrophic commands" such as `rm -rf /` / `rm -rf ~` are forced to ask.
 
 ## Extending Permissions with Hooks
 
@@ -274,7 +270,7 @@ Hook exit code semantics:
 
 Notes:
 
-- **deny / ask rules always take effect before hooks**. A hook returning `"allow"` cannot bypass deny in settings. This matches cc behavior
+- **deny / ask rules always take effect before hooks**. A hook returning `"allow"` cannot bypass deny in settings
 - However, **blocking hooks** (exit code 2) can short-circuit allow rules before Phase 1, so you can "allow all Bash first, but use hooks to separately block a few specific commands"
 
 ## Working with Sandboxing
@@ -301,9 +297,9 @@ projectSettings > localSettings > command/sandbox sources
 
 However, the **evaluation order** is more important than settings priority:
 
-- `deny` arrays are merged from all scopes (`PermissionUtils.mergeRulesFromAllSources`), and **a deny in any scope rejects**
-- `allow` arrays are merged twice by "trusted / untrusted": user/cli/flag/session/policy are always included in the trusted merge; project/local are considered trusted only when the directory is trusted
-- `disableBypassPermissionsMode` takes effect when it is `"disable"` in any of the four layers: `user / project / local / cliArg` (see `tool-permission-service.ts:670-673`) — this adds a project-level hard-disable channel compared with cc
+- `deny` arrays are merged from all scopes, and **a deny in any scope rejects**
+- `allow` arrays are merged twice by "trusted / untrusted": user / cli / flag / session / policy are always included in the trusted merge; project / local are considered trusted only when the directory is trusted
+- `disableBypassPermissionsMode` takes effect when it is `"disable"` in any of the four layers: user / project / local / CLI startup flag
 
 ## Example Configurations
 

package/dist/web-ui/docs/en/cli/tools-reference.md

@@ -22,11 +22,14 @@ CodeBuddy Code includes a set of built-in tools to help understand and modify yo
 | `ImageEdit` | Edits or modifies existing images based on text instructions | Yes |
 | `ImageGen` | Generates images from text descriptions | Yes |
 | `LeaveWorktree` | Exits the worktree session and returns to the original directory | Yes |
+| `ListMcpResources` | Lists all resources/templates exposed by connected [MCP servers](mcp.md); optionally filtered by server name | No |
 | `LSP` | Provides code intelligence via Language Server. Automatically reports type errors and warnings after file edits. Also supports navigation operations such as go-to-definition, find references, get type info, list symbols, find implementations, and trace call hierarchies. Requires a [Code Intelligence Plugin](plugins.md) and its language server binary | No |
 | `MultiEdit` | Performs multiple edits on the same file in a single atomic operation | Yes |
 | `NotebookEdit` | Modifies Jupyter notebook cell contents | Yes |
+| `NotebookRead` | Reads Jupyter notebook cell contents; specify `cell_id` to read a single cell | No |
 | `PowerShell` | Executes PowerShell commands on Windows. Only available on Windows, see [PowerShell Tool Behavior](#powershell-tool-behavior) | Yes |
 | `Read` | Reads file contents, supporting images, PDFs, and Jupyter notebooks | No |
+| `ReadMcpResource` | Reads the content of a specific MCP resource by server + URI; pairs with `ListMcpResources` | Yes |
 | `SendMessage` | Sends messages to teammates in an [Agent Team](agent-teams.md) | No |
 | `Skill` | Executes a [Skill](skills.md) in the main conversation | No |
 | `SlashCommand` | Executes a custom [slash command](slash-commands.md) | Yes |
@@ -40,8 +43,10 @@ CodeBuddy Code includes a set of built-in tools to help understand and modify yo
 | `TeamCreate` | Creates an [Agent Team](agent-teams.md) for coordinating multiple agents | No |
 | `TeamDelete` | Deletes an Agent Team and its task directory | No |
 | `ToolSearch` | Searches and loads deferred tools, supporting both built-in tools and [MCP tools](mcp.md#deferred-loading-defer_loading) | No |
+| `WaitForMcpServers` | Waits for the specified MCP servers to finish connecting (defaults to all pending servers), with a 5-second timeout | No |
 | `WebFetch` | Fetches content from a specified URL and performs AI analysis | Yes |
 | `WebSearch` | Performs a web search | Yes |
+| `Workflow` | Launches a [Dynamic Workflow](workflows.md) asynchronously, returns a runId immediately, and runs in the background; pull results via `TaskOutput` | Yes |
 | `Write` | Creates or overwrites files | Yes |
 
 Permission rules can be configured via the `/permissions` command or in [permission settings](settings.md#permission-settings). See also [Tool-Specific Permission Rules](iam.md#tool-specific-permission-rules).
@@ -104,18 +109,6 @@ The PowerShell tool includes a built-in security checker covering dangerous patt
 
 Some tools (such as those provided via [MCP servers](mcp.md)) use deferred loading. These tools do not appear in the initial tool list and must be discovered and activated via `ToolSearch`. Once activated, tools remain available for the rest of the session.
 
-Tools can be configured as deferred via product configuration:
-
-```json
-{
-  "tools": {
-    "ToolName": {
-      "deferLoading": true
-    }
-  }
-}
-```
-
 ## See Also
 
 * [Identity and Access Management](iam.md): Permission system, rule syntax, and tool-specific rules

package/dist/web-ui/docs/en/cli/workflows.md

@@ -1,9 +1,9 @@
-# Dynamic Workflows: Orchestrating Large-Scale Subagents with Scripts
+# Dynamic Workflows
 
 > Dynamic Workflows let CodeBuddy write a JavaScript orchestration script that the runtime executes in the background to coordinate dozens or even hundreds of subagents on a task. The script itself is readable, editable, and rerunnable, making it suitable for codebase audits, large migrations, and research tasks that require cross-validation.
 
 <Note>
-Dynamic Workflows are currently a research preview and require CodeBuddy Code v2.1.154 or later. Enable them with the "Dynamic workflows" toggle in `/config`.
+Dynamic Workflows are currently a research preview and require CodeBuddy Code v2.105.0 or later. They are enabled by default; to turn them off, toggle "Dynamic workflows" in `/config`.
 </Note>
 
 A Dynamic Workflow is a JavaScript script that CodeBuddy writes on the spot for your task. The runtime executes it in the background while your session stays responsive. The script contains one or more [`agent()`](#script-api) calls; each call dispatches an independent subagent to work. After the script receives intermediate results, it can branch, run work in parallel, or dispatch the next batch of subagents.
@@ -81,7 +81,7 @@ CodeBuddy Code includes the following Workflow:
 
 | Command                       | Purpose                                                                                                                                                                                                        |
 | :---------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `/deep-research <question>`   | Searches, fetches, and cross-validates sources from multiple angles in parallel, votes on each claim, removes parts that fail validation, and outputs a cited report. Requires the [WebSearch tool](tools-reference.md#websearch-tool-behavior). |
+| `/deep-research <question>`   | Searches, fetches, and cross-validates sources from multiple angles in parallel, votes on each claim, removes parts that fail validation, and outputs a cited report. Requires the [WebSearch tool](tools-reference.md). |
 
 [Workflows you save yourself](#saving-a-workflow-for-reuse) are registered as commands in the same way and appear together with built-in Workflows in `/` autocomplete.
 
@@ -235,8 +235,6 @@ The script is a self-contained JavaScript module and can use the following globa
 | `args`                        | Arguments passed by the caller (see [Passing Arguments to a Saved Workflow](#passing-arguments-to-a-saved-workflow))                  |
 | `workflow(name, args?)`       | Calls a **saved** Workflow as a nested Workflow (only exposed to the parent; child Workflows do not expose this hook again, and deep nesting is forbidden) |
 
-For more patterns, see [`build/patches/cli-saas/templates/workflow-tool-description.tpl`](../../../build/patches/cli-saas/templates/workflow-tool-description.tpl) and [`workflow-subagent-system-preamble.tpl`](../../../build/patches/cli-saas/templates/workflow-subagent-system-preamble.tpl).
-
 ## Run Management
 
 After a run starts, manage it from the `/workflows` view. You can also expand the progress row in the task panel below the input box.
@@ -268,7 +266,7 @@ Disable it only for yourself:
 - Set `"disableWorkflows": true` in `~/.codebuddy/settings.json`. This persists
 - Set the environment variable `CODEBUDDY_DISABLE_WORKFLOWS=1`. It is read at startup and takes effect wherever it is set
 
-Disable it for the whole organization: set `"disableWorkflows": true` in [managed settings](settings.md#enterprise-managed-policy-settings).
+Disable it for the whole organization: set `"disableWorkflows": true` in [managed settings](settings.md).
 
 After disabling, built-in Workflow commands are unavailable, the keyword `ultracode` no longer triggers Workflow, and the `/effort` menu no longer shows the ultracode option.