@tencent-ai/agent-sdk 0.3.155 → 0.3.158
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/cli/CHANGELOG.md +53 -0
- package/cli/dist/codebuddy-headless.js +218 -211
- package/cli/dist/web-ui/assets/index-C5x-jWxM.css +32 -0
- package/cli/dist/web-ui/assets/{index-bVNRRvKC.js → index-CU_ExRgj.js} +179 -167
- package/cli/dist/web-ui/assets/workbox-window.prod.es5-BBnX5xw4.js +2 -0
- package/cli/dist/web-ui/docs/cn/cli/codebuddy-dir.md +309 -0
- package/cli/dist/web-ui/docs/cn/cli/env-vars.md +21 -0
- package/cli/dist/web-ui/docs/cn/cli/goal.md +161 -0
- package/cli/dist/web-ui/docs/cn/cli/hooks.md +12 -4
- package/cli/dist/web-ui/docs/cn/cli/http-api.md +6 -0
- package/cli/dist/web-ui/docs/cn/cli/ide-integrations.md +2 -1
- package/cli/dist/web-ui/docs/cn/cli/monitoring.md +87 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/README.md +9 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.96.1.md +17 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.0.md +186 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.1.md +24 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.2.md +16 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.3.md +17 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.4.md +9 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.97.5.md +20 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.98.0.md +48 -0
- package/cli/dist/web-ui/docs/cn/cli/release-notes/v2.98.1.md +19 -0
- package/cli/dist/web-ui/docs/cn/cli/slash-commands.md +1 -0
- package/cli/dist/web-ui/docs/en/cli/codebuddy-dir.md +309 -0
- package/cli/dist/web-ui/docs/en/cli/env-vars.md +23 -2
- package/cli/dist/web-ui/docs/en/cli/goal.md +161 -0
- package/cli/dist/web-ui/docs/en/cli/hooks.md +10 -2
- package/cli/dist/web-ui/docs/en/cli/http-api.md +6 -0
- package/cli/dist/web-ui/docs/en/cli/ide-integrations.md +2 -1
- package/cli/dist/web-ui/docs/en/cli/monitoring.md +87 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/README.md +9 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.96.1.md +17 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.0.md +186 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.1.md +24 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.2.md +16 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.3.md +17 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.4.md +9 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.97.5.md +20 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.98.0.md +48 -0
- package/cli/dist/web-ui/docs/en/cli/release-notes/v2.98.1.md +19 -0
- package/cli/dist/web-ui/docs/en/cli/slash-commands.md +1 -0
- package/cli/dist/web-ui/docs/search-index-en.json +1 -1
- package/cli/dist/web-ui/docs/search-index-zh.json +1 -1
- package/cli/dist/web-ui/docs/sidebar-en.json +1 -1
- package/cli/dist/web-ui/docs/sidebar-zh.json +1 -1
- package/cli/dist/web-ui/index.html +2 -2
- package/cli/dist/web-ui/sw.js +1 -1
- package/cli/dist/web-ui/{workbox-e082a648.js → workbox-fed2bdfe.js} +1 -1
- package/cli/package.json +1 -1
- package/cli/product.cloudhosted.json +281 -3
- package/cli/product.internal.json +4 -3
- package/cli/product.ioa.json +25 -3
- package/cli/product.json +27 -5
- package/cli/product.selfhosted.json +4 -3
- package/lib/auth.js +3 -2
- package/lib/auth.js.map +1 -1
- package/lib/connect.js +3 -2
- package/lib/connect.js.map +1 -1
- package/lib/index.js +1 -1
- package/lib/mcp/create-sdk-mcp-server.js +3 -2
- package/lib/mcp/create-sdk-mcp-server.js.map +1 -1
- package/lib/plugin.js +13 -22
- package/lib/plugin.js.map +1 -1
- package/lib/query.d.ts.map +1 -1
- package/lib/query.js +2 -2
- package/lib/query.js.map +1 -1
- package/lib/session.js +4 -4
- package/lib/session.js.map +1 -1
- package/lib/transport/index.js +2 -2
- package/lib/transport/index.js.map +1 -1
- package/lib/transport/process-transport.js +7 -17
- package/lib/transport/process-transport.js.map +1 -1
- package/lib/utils/cli-resolver.js +6 -6
- package/lib/utils/cli-resolver.js.map +1 -1
- package/lib/utils/env-utils.js +2 -1
- package/lib/utils/env-utils.js.map +1 -1
- package/lib/utils/process.js +2 -1
- package/lib/utils/process.js.map +1 -1
- package/lib/utils/type-guards.js +2 -1
- package/lib/utils/type-guards.js.map +1 -1
- package/package.json +1 -1
- package/cli/dist/web-ui/assets/index-CY6b2fbj.css +0 -32
- package/cli/dist/web-ui/assets/workbox-window.prod.es5-BIl4cyR9.js +0 -2
|
@@ -0,0 +1,309 @@
|
|
|
1
|
+
# .codebuddy Directory Structure
|
|
2
|
+
|
|
3
|
+
> A deep dive into the files and subdirectories under CodeBuddy Code's configuration directory `~/.codebuddy` and the project-level `.codebuddy` directory.
|
|
4
|
+
|
|
5
|
+
CodeBuddy Code uses two configuration directories:
|
|
6
|
+
|
|
7
|
+
- **Global directory** `~/.codebuddy/`: stores user-level configuration, history, runtime data, etc., affecting all projects
|
|
8
|
+
- **Project directory** `.codebuddy/` (located at the project root): stores project-level configuration, rules, skills, commands, etc., shared with the team via version control
|
|
9
|
+
|
|
10
|
+
|
|
11
|
+
### User-Level Extension Directories
|
|
12
|
+
|
|
13
|
+
#### `agents/`
|
|
14
|
+
|
|
15
|
+
Stores user-level custom sub-agents that take effect across all projects. Each agent is a single `.md` file:
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
~/.codebuddy/agents/
|
|
19
|
+
├── code-reviewer.md # Code review agent
|
|
20
|
+
└── translator.md # Translation agent
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
File format (YAML frontmatter + system prompt):
|
|
24
|
+
|
|
25
|
+
```markdown
|
|
26
|
+
---
|
|
27
|
+
name: code-reviewer
|
|
28
|
+
description: Code review expert; use proactively after writing code
|
|
29
|
+
tools: Read, Grep, Glob, Bash
|
|
30
|
+
model: inherit
|
|
31
|
+
---
|
|
32
|
+
|
|
33
|
+
You are a senior code reviewer focused on code quality, security, and best practices...
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
See [Sub-Agent Documentation](sub-agents.md) for details.
|
|
37
|
+
|
|
38
|
+
#### `rules/`
|
|
39
|
+
|
|
40
|
+
Stores user-level rule files that take effect across all projects. All `.md` files are loaded automatically; subdirectories are supported:
|
|
41
|
+
|
|
42
|
+
```
|
|
43
|
+
~/.codebuddy/rules/
|
|
44
|
+
├── preferences.md # Personal coding preferences
|
|
45
|
+
└── workflows.md # Common workflow conventions
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Rule files support frontmatter to control loading behavior:
|
|
49
|
+
|
|
50
|
+
```markdown
|
|
51
|
+
---
|
|
52
|
+
alwaysApply: false
|
|
53
|
+
paths: src/**/*.ts
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
# TypeScript Conventions
|
|
57
|
+
|
|
58
|
+
- Prefer `interface` over `type`
|
|
59
|
+
- Disallow `any`
|
|
60
|
+
```
|
|
61
|
+
|
|
62
|
+
See [Memory Management - Rule System](memory.md#using-codebuddyrules-for-modular-rules) for details.
|
|
63
|
+
|
|
64
|
+
#### `skills/`
|
|
65
|
+
|
|
66
|
+
Stores user-level skills that take effect across all projects. Each skill is a self-contained directory containing a `SKILL.md`:
|
|
67
|
+
|
|
68
|
+
```
|
|
69
|
+
~/.codebuddy/skills/
|
|
70
|
+
└── pdf/
|
|
71
|
+
└── SKILL.md
|
|
72
|
+
```
|
|
73
|
+
|
|
74
|
+
See [Skills Documentation](skills.md) for details.
|
|
75
|
+
|
|
76
|
+
---
|
|
77
|
+
|
|
78
|
+
### Runtime Data Directories
|
|
79
|
+
|
|
80
|
+
These directories are maintained automatically by CodeBuddy Code and typically do not require manual operation:
|
|
81
|
+
|
|
82
|
+
| Directory | Description |
|
|
83
|
+
|------|------|
|
|
84
|
+
| `projects/` | Per-project runtime data, including session records (`.jsonl`) and sub-agent tool output (`tool-results/`) |
|
|
85
|
+
| `sessions/` | Active session data |
|
|
86
|
+
| `plans/` | Plan files generated in plan mode |
|
|
87
|
+
| `logs/` | Runtime logs grouped by date and process |
|
|
88
|
+
| `traces/` | OpenTelemetry execution trace data |
|
|
89
|
+
| `file-history/` | Snapshots of files operated on within each session, used by `/rewind` |
|
|
90
|
+
| `history.jsonl` | Global conversation history (used by `/resume`) |
|
|
91
|
+
| `blobs/` | Binary resources such as images and screenshots, stored by content hash |
|
|
92
|
+
| `tasks/` | Task management system data (TaskCreate/TaskUpdate) |
|
|
93
|
+
| `teams/` | Agent team (TeamCreate) runtime data |
|
|
94
|
+
| `shell-snapshots/` | Bash sandbox startup snapshots that speed up sandbox creation |
|
|
95
|
+
| `plugins/` | File contents of installed plugins |
|
|
96
|
+
| `local_storage/` | CLI internal key-value persistent storage (`.info` files named by content hash) |
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Project Directory `.codebuddy/`
|
|
101
|
+
|
|
102
|
+
Located at the project root and intended to be committed to version control so the team can share it:
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
.codebuddy/
|
|
106
|
+
├── settings.json # Project shared configuration
|
|
107
|
+
├── settings.local.json # Local personal configuration (auto-ignored by .gitignore)
|
|
108
|
+
├── CODEBUDDY.md # Project-level memory file
|
|
109
|
+
│
|
|
110
|
+
├── agents/ # Project-level custom sub-agents
|
|
111
|
+
├── rules/ # Project-level rule files
|
|
112
|
+
├── skills/ # Project-level skills
|
|
113
|
+
├── commands/ # Custom slash commands
|
|
114
|
+
```
|
|
115
|
+
|
|
116
|
+
### Configuration Files
|
|
117
|
+
|
|
118
|
+
#### `settings.json`
|
|
119
|
+
|
|
120
|
+
Project shared configuration synced with the team via version control. Suitable for setting team-wide model, permission rules, plugins, and so on:
|
|
121
|
+
|
|
122
|
+
```json
|
|
123
|
+
{
|
|
124
|
+
"permissions": {
|
|
125
|
+
"allow": ["Read", "Edit", "Bash(git:*)", "Bash(npm:*)"],
|
|
126
|
+
"deny": ["Read(./.env)", "Read(./secrets/**)"]
|
|
127
|
+
},
|
|
128
|
+
"enabledPlugins": {
|
|
129
|
+
"pr-review-toolkit@company-tools": true
|
|
130
|
+
},
|
|
131
|
+
"extraKnownMarketplaces": {
|
|
132
|
+
"company-tools": {
|
|
133
|
+
"source": {
|
|
134
|
+
"source": "github",
|
|
135
|
+
"repo": "myorg/codebuddy-plugins"
|
|
136
|
+
}
|
|
137
|
+
}
|
|
138
|
+
}
|
|
139
|
+
}
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
#### `settings.local.json`
|
|
143
|
+
|
|
144
|
+
Local personal configuration. CodeBuddy Code automatically adds it to `.gitignore`. Suitable for personal overrides (such as local debug ports or personal keys) that should not affect other team members.
|
|
145
|
+
|
|
146
|
+
#### `CODEBUDDY.md`
|
|
147
|
+
|
|
148
|
+
Project-level memory file shared via version control. Stores team knowledge such as project architecture, conventions, and common commands:
|
|
149
|
+
|
|
150
|
+
```markdown
|
|
151
|
+
# Project Overview
|
|
152
|
+
|
|
153
|
+
This project is a TypeScript monorepo (Yarn workspaces).
|
|
154
|
+
|
|
155
|
+
## Common Commands
|
|
156
|
+
|
|
157
|
+
- `yarn build` — build all packages
|
|
158
|
+
- `yarn test` — run all tests
|
|
159
|
+
|
|
160
|
+
## Architectural Conventions
|
|
161
|
+
|
|
162
|
+
- Uses the CellJS dependency injection framework
|
|
163
|
+
- Protocol definitions live in `*-protocol.ts` files
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
> **Tip**: You can also place the memory file at the project root as `CODEBUDDY.md` (outside the `.codebuddy/` directory). Both locations are equivalent.
|
|
167
|
+
|
|
168
|
+
---
|
|
169
|
+
|
|
170
|
+
### Project-Level Extension Directories
|
|
171
|
+
|
|
172
|
+
#### `agents/`
|
|
173
|
+
|
|
174
|
+
Stores project-specific sub-agents, which take precedence over user-level agents. When names collide, the project-level agent overrides the user-level one.
|
|
175
|
+
|
|
176
|
+
```
|
|
177
|
+
.codebuddy/agents/
|
|
178
|
+
├── blog-translator.md # Blog translation agent
|
|
179
|
+
└── docs-reviewer.md # Documentation review agent
|
|
180
|
+
```
|
|
181
|
+
|
|
182
|
+
#### `rules/`
|
|
183
|
+
|
|
184
|
+
Stores project-level rules shared via version control. Suitable for team-wide code conventions, workflow agreements, etc. Subdirectories are supported:
|
|
185
|
+
|
|
186
|
+
```
|
|
187
|
+
.codebuddy/rules/
|
|
188
|
+
├── code-style.md # Code style conventions
|
|
189
|
+
├── testing.md # Testing conventions
|
|
190
|
+
├── security.md # Security requirements
|
|
191
|
+
└── frontend/
|
|
192
|
+
├── react.md # React component conventions
|
|
193
|
+
└── styles.md # Styling conventions
|
|
194
|
+
```
|
|
195
|
+
|
|
196
|
+
All `.md` files are recursively loaded automatically.
|
|
197
|
+
|
|
198
|
+
#### `skills/`
|
|
199
|
+
|
|
200
|
+
Stores project-level skills. Each skill is its own directory containing a `SKILL.md` and optional supporting files:
|
|
201
|
+
|
|
202
|
+
```
|
|
203
|
+
.codebuddy/skills/
|
|
204
|
+
├── case-executor/
|
|
205
|
+
│ ├── SKILL.md # Skill definition
|
|
206
|
+
│ ├── scripts/ # Helper scripts
|
|
207
|
+
│ └── references/ # Reference materials
|
|
208
|
+
└── cnb-api/
|
|
209
|
+
└── SKILL.md
|
|
210
|
+
```
|
|
211
|
+
|
|
212
|
+
`SKILL.md` format:
|
|
213
|
+
|
|
214
|
+
```markdown
|
|
215
|
+
---
|
|
216
|
+
name: case-executor
|
|
217
|
+
description: Executes JSON test cases and generates reports
|
|
218
|
+
allowed-tools: Read, Write, Bash
|
|
219
|
+
---
|
|
220
|
+
|
|
221
|
+
You are a test execution expert responsible for running UI test cases in JSON format...
|
|
222
|
+
```
|
|
223
|
+
|
|
224
|
+
See [Skills Documentation](skills.md) for details.
|
|
225
|
+
|
|
226
|
+
#### `commands/`
|
|
227
|
+
|
|
228
|
+
Stores custom slash commands invoked via `/command-name`. Nested directories are supported (invoked using `/group:command`):
|
|
229
|
+
|
|
230
|
+
```
|
|
231
|
+
.codebuddy/commands/
|
|
232
|
+
├── deploy.md # /deploy command
|
|
233
|
+
├── team/
|
|
234
|
+
│ ├── issue-start.md # /team:issue-start command
|
|
235
|
+
│ └── create-issue.md # /team:create-issue command
|
|
236
|
+
└── openspec/
|
|
237
|
+
└── propose.md # /openspec:propose command
|
|
238
|
+
```
|
|
239
|
+
|
|
240
|
+
Command file format:
|
|
241
|
+
|
|
242
|
+
```markdown
|
|
243
|
+
---
|
|
244
|
+
description: Create a new Issue
|
|
245
|
+
argument-hint: "<description> ; <type> ; <product>"
|
|
246
|
+
allowed-tools: Bash
|
|
247
|
+
---
|
|
248
|
+
|
|
249
|
+
Create an Issue based on the following description: $ARGUMENTS
|
|
250
|
+
```
|
|
251
|
+
|
|
252
|
+
See [Slash Command Documentation](slash-commands.md) for details.
|
|
253
|
+
|
|
254
|
+
---
|
|
255
|
+
|
|
256
|
+
## Configuration Priority
|
|
257
|
+
|
|
258
|
+
Multi-layer configuration is applied with the following priority (higher priority overrides lower priority):
|
|
259
|
+
|
|
260
|
+
```
|
|
261
|
+
Command-line arguments (highest priority)
|
|
262
|
+
↓
|
|
263
|
+
.codebuddy/settings.local.json (project local, not committed)
|
|
264
|
+
↓
|
|
265
|
+
.codebuddy/settings.json (project shared, team-wide)
|
|
266
|
+
↓
|
|
267
|
+
~/.codebuddy/settings.json (user global, personal preferences)
|
|
268
|
+
↓
|
|
269
|
+
Built-in product defaults (lowest priority)
|
|
270
|
+
```
|
|
271
|
+
|
|
272
|
+
Priority for agents/skills/rules: **project-level > user-level > plugin-level**. When names collide, the project level wins.
|
|
273
|
+
|
|
274
|
+
## Memory Loading Order
|
|
275
|
+
|
|
276
|
+
```
|
|
277
|
+
1. User-level memory: ~/.codebuddy/CODEBUDDY.md
|
|
278
|
+
2. User-level rules: ~/.codebuddy/rules/*.md (recursive)
|
|
279
|
+
3. Project-level memory: CODEBUDDY.md (searched recursively upward from cwd)
|
|
280
|
+
4. Project-level rules: .codebuddy/rules/*.md (cwd only, no upward search)
|
|
281
|
+
5. Project local memory: CODEBUDDY.local.md
|
|
282
|
+
6. Subdirectory memory: dynamically loaded `CODEBUDDY.md` from a subdirectory when tools operate on files there
|
|
283
|
+
```
|
|
284
|
+
|
|
285
|
+
## Version Control Recommendations
|
|
286
|
+
|
|
287
|
+
| File / Directory | Commit to VCS | Notes |
|
|
288
|
+
|-----------|:---:|------|
|
|
289
|
+
| `.codebuddy/settings.json` | ✅ Recommended | Team shared configuration |
|
|
290
|
+
| `.codebuddy/settings.local.json` | ❌ Do not commit | Auto-added to .gitignore |
|
|
291
|
+
| `CODEBUDDY.md` / `.codebuddy/CODEBUDDY.md` | ✅ Recommended | Team shared knowledge |
|
|
292
|
+
| `CODEBUDDY.local.md` | ❌ Do not commit | Auto-added to .gitignore |
|
|
293
|
+
| `.codebuddy/agents/` | ✅ Recommended | Team shared sub-agents |
|
|
294
|
+
| `.codebuddy/rules/` | ✅ Recommended | Team shared rules |
|
|
295
|
+
| `.codebuddy/skills/` | ✅ Recommended | Team shared skills |
|
|
296
|
+
| `.codebuddy/commands/` | ✅ Recommended | Team shared commands |
|
|
297
|
+
|
|
298
|
+
## Related Resources
|
|
299
|
+
|
|
300
|
+
- [Settings](settings.md) — Complete configuration field reference
|
|
301
|
+
- [Memory Management](memory.md) — Detailed guide to CODEBUDDY.md and the rule system
|
|
302
|
+
- [Sub-Agents](sub-agents.md) — Create and use custom sub-agents
|
|
303
|
+
- [Skills Documentation](skills.md) — In-depth guide to the skill system
|
|
304
|
+
- [Slash Commands](slash-commands.md) — Custom command reference
|
|
305
|
+
- [MCP Documentation](mcp.md) — MCP server configuration
|
|
306
|
+
|
|
307
|
+
---
|
|
308
|
+
|
|
309
|
+
*Use the `.codebuddy` directory wisely to help CodeBuddy Code better understand your project and team conventions.*
|
|
@@ -39,8 +39,10 @@ CodeBuddy Code supports environment variables to control its behavior. These var
|
|
|
39
39
|
| `BASH_DEFAULT_TIMEOUT_MS` | Default timeout for long-running bash commands (default: 120000) |
|
|
40
40
|
| `BASH_MAX_OUTPUT_LENGTH` | Maximum characters of bash output retained in memory (default: 30000, max: 150000). Content exceeding the limit is mid-truncated (keeping head 20% + tail 80%), and the full output is automatically saved to disk |
|
|
41
41
|
| `BASH_MAX_TIMEOUT_MS` | Maximum timeout the model can set for long-running bash commands (default: 600000) |
|
|
42
|
-
| `CODEBUDDY_BASH_ASSISTANT_BUDGET_MS` | Main conversation response budget (milliseconds, default `0`=off). When set to `>0`, foreground Bash/PowerShell commands in the main session that exceed this duration are automatically converted into background tasks to keep the conversation responsive. Sub-agents are not affected by this budget. Aligns with
|
|
42
|
+
| `CODEBUDDY_BASH_ASSISTANT_BUDGET_MS` | Main conversation response budget (milliseconds, default `0`=off). When set to `>0`, foreground Bash/PowerShell commands in the main session that exceed this duration are automatically converted into background tasks to keep the conversation responsive. Sub-agents are not affected by this budget. Aligns with CodeBuddy Code's `ASSISTANT_BLOCKING_BUDGET_MS` (the official default value is `15000`) |
|
|
43
43
|
| `CODEBUDDY_BASH_AUTO_BACKGROUND_DISABLED` | Set to `1` to disable timeout auto-backgrounding; foreground commands fall back to the old SIGTERM/kill hard-kill behavior on timeout. Only used for debugging or temporary rollback when encountering regressions; keep the default (unset) in normal scenarios |
|
|
44
|
+
| `CODEBUDDY_BASH_BG_MAX_OUTPUT_BYTES` | Total byte limit for the on-disk file of stdout+stderr for background bash tasks (default `52428800` = 50MB). When exceeded, the size watchdog fires `SIGKILL` and marks the task as `killed`, with a notice injected at the end of stderr. CodeBuddy Code in `ShellCommand.ts` hardcodes the equivalent threshold as a constant; here it is exposed as an env var for operators to tune. Only effective in file fd mode (in pipe mode, child process output is not persisted to disk) |
|
|
45
|
+
| `CODEBUDDY_BASH_BG_PIPE_MODE` | Set to `1` to force background tasks back to pipe mode (not using file fds), for rollback or debugging. The default (unset) uses file fd mode, which solves the zombie process issue caused by grandchild processes (e.g., spawned via `nohup`) holding parent pipe fds; the sandbox path automatically falls back to pipe and does not require explicit setting. There is no equivalent toggle elsewhere; this is a CodeBuddy Code fallback to remain compatible with legacy sandbox/PTY paths |
|
|
44
46
|
|
|
45
47
|
## Tool Output Externalization
|
|
46
48
|
|
|
@@ -64,6 +66,7 @@ CodeBuddy Code supports environment variables to control its behavior. These var
|
|
|
64
66
|
| `CODEBUDDY_DEFER_TOOL_LOADING` | Set to `false` or `0` to disable MCP tool deferred loading |
|
|
65
67
|
| `CODEBUDDY_SHOW_ALL_DEFERRED_TOOLS` | Set to `true` or `1` to show full descriptions for all deferred tools |
|
|
66
68
|
| `CODEBUDDY_DISABLE_CRON` | Set to `1` to disable scheduled tasks |
|
|
69
|
+
| `CODEBUDDY_DISABLE_FORK_SUBAGENT` | Set to `1` to disable the Agent tool's fork sub-agent mode (`subagent_type="fork"`). When enabled, the fork-mode section is automatically hidden from the Agent tool description, so the model will not see this feature; if the model still passes `subagent_type="fork"`, the runtime falls back to a custom agent named `fork` (e.g., one defined by the user at `.codebuddy/agents/fork.md`), or otherwise rewrites it to a `general-purpose` regular sub-agent. Useful for host scenarios that need to avoid request amplification caused by recursive fork spawning |
|
|
67
70
|
| `CODEBUDDY_REHYDRATE_IMAGE_BLOB_REFS` | Set to `true` to rehydrate image blob references to full base64 data in `-p` mode streaming output. Useful for downstream integrations that need direct access to image data |
|
|
68
71
|
|
|
69
72
|
## Context and Memory
|
|
@@ -145,6 +148,24 @@ CodeBuddy Code supports environment variables to control its behavior. These var
|
|
|
145
148
|
| `DISABLE_AUTOUPDATER` | Set to `1` to disable auto-updates |
|
|
146
149
|
| `DISABLE_FEEDBACK_COMMAND` | Set to `1` to disable the `/feedback` command |
|
|
147
150
|
|
|
151
|
+
### OpenTelemetry Custom Reporting (traces)
|
|
152
|
+
|
|
153
|
+
CodeBuddy Code supports reporting internal traces to your own Collector via the OTLP protocol. Environment variables follow the [OpenTelemetry specification](https://opentelemetry.io/docs/specs/otel/protocol/exporter/). For detailed usage, see [Monitoring](monitoring.md).
|
|
154
|
+
|
|
155
|
+
| Environment Variable | Description |
|
|
156
|
+
|---------|------|
|
|
157
|
+
| `CODEBUDDY_CODE_ENABLE_TELEMETRY` | Set to `1` to enable OTel custom reporting; the legacy alias `CLAUDE_CODE_ENABLE_TELEMETRY` is also accepted for backward compatibility |
|
|
158
|
+
| `OTEL_TRACES_EXPORTER` | `otlp` (default) / `console` (output to logs, useful for debugging) / `none` (off) |
|
|
159
|
+
| `OTEL_EXPORTER_OTLP_ENDPOINT` | Generic OTLP endpoint; the tool automatically appends `/v1/traces` |
|
|
160
|
+
| `OTEL_EXPORTER_OTLP_TRACES_ENDPOINT` | Traces-specific endpoint, used as a complete URL; takes priority over the generic variable |
|
|
161
|
+
| `OTEL_EXPORTER_OTLP_HEADERS` | OTLP request headers in the format `k1=v1,k2=v2`; values support URL encoding |
|
|
162
|
+
| `OTEL_EXPORTER_OTLP_TRACES_HEADERS` | Traces-specific request headers; takes priority over the generic variable |
|
|
163
|
+
| `OTEL_EXPORTER_OTLP_PROTOCOL` | Only `http/protobuf` (default) is supported; other values (such as `grpc`, `http/json`) fall back and emit a warning |
|
|
164
|
+
| `OTEL_SERVICE_NAME` | Override the default `service.name` |
|
|
165
|
+
| `OTEL_RESOURCE_ATTRIBUTES` | Resource attributes in the format `k1=v1,k2=v2`; merged into the trace resource |
|
|
166
|
+
|
|
167
|
+
> When `DISABLE_TELEMETRY=1`, OTel reporting is turned off regardless of the variables above.
|
|
168
|
+
|
|
148
169
|
## Tasks and Background Work
|
|
149
170
|
|
|
150
171
|
| Environment Variable | Description |
|
|
@@ -257,7 +278,7 @@ codebuddy --model your-model-name
|
|
|
257
278
|
|
|
258
279
|
#### Connecting to DeepSeek Example
|
|
259
280
|
|
|
260
|
-
To connect to any third-party model service compatible with the
|
|
281
|
+
To connect to any third-party model service compatible with the protocol (such as DeepSeek), you only need to configure the Base URL, API Key, and model variables — no additional `models.json` modifications are required:
|
|
261
282
|
|
|
262
283
|
```bash
|
|
263
284
|
# Endpoint and key
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
# Keep CodeBuddy Working Until a Goal Is Met
|
|
2
|
+
|
|
3
|
+
> Use `/goal` to set a completion condition. CodeBuddy will keep working across multiple turns until the condition is satisfied before handing control back to you.
|
|
4
|
+
|
|
5
|
+
> **Version requirement**: The `/goal` command requires `@tencent-ai/codebuddy-code` with the goal feature included (the `GoalService` module in agent-cli).
|
|
6
|
+
|
|
7
|
+
`/goal` sets a completion condition that CodeBuddy continuously works toward without you prompting it step by step. At the end of each turn, a small-fast model evaluator checks whether the condition holds — if not, CodeBuddy automatically starts the next turn rather than returning control to you. Once the condition is met, the goal is automatically cleared.
|
|
8
|
+
|
|
9
|
+
`/goal` is suitable for tracking substantial work that has a verifiable end state:
|
|
10
|
+
|
|
11
|
+
- Migrating a module to a new API until all call sites compile and tests pass
|
|
12
|
+
- Implementing a design doc until all acceptance criteria are met
|
|
13
|
+
- Splitting a large file into focused modules until each one is within the size budget
|
|
14
|
+
- Processing a list of issues with a certain label until the queue is empty
|
|
15
|
+
|
|
16
|
+
This document covers:
|
|
17
|
+
|
|
18
|
+
- [Comparison with other autonomous workflows](#comparison-with-other-autonomous-workflows): choosing between `/goal`, `/loop`, and Stop hooks
|
|
19
|
+
- [Setting a goal](#setting-a-goal) and [tips for writing effective conditions](#writing-an-effective-condition)
|
|
20
|
+
- [Checking status](#checking-status), [clearing early](#clearing-a-goal-early), [running in non-interactive mode](#running-in-non-interactive-mode)
|
|
21
|
+
- [How the evaluator works](#how-the-evaluator-works)
|
|
22
|
+
- [Implementation notes and known limitations](#implementation-notes-and-known-limitations)
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
## Using `/goal`
|
|
26
|
+
|
|
27
|
+
Each session can only have one active goal at a time. The same command takes on the role of "set / view / clear" depending on the arguments.
|
|
28
|
+
|
|
29
|
+
### Setting a Goal
|
|
30
|
+
|
|
31
|
+
Follow `/goal` with the condition you want to satisfy. If there is already an active goal, the new one replaces it (the old goal's hook is automatically unregistered).
|
|
32
|
+
|
|
33
|
+
```text
|
|
34
|
+
/goal all tests in test/auth pass and the lint step is clean
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
Once set, CodeBuddy **immediately starts a turn**, passing "the condition itself" as the instruction to the main agent — you don't need to send an additional prompt. A `⊚ /goal active (Xs)` indicator also appears at the bottom-right of the input box, refreshing every second with the elapsed time, so you always know when goal mode is active.
|
|
38
|
+
|
|
39
|
+
After each turn, the evaluator returns a short reason explaining "why the condition is / is not yet met." This reason is injected into the conversation history as an `isMeta=true` internal message, allowing the model to see the evaluator's perspective on the next turn and precisely address what is missing — this is the key mechanism for the model to "know what steps remain."
|
|
40
|
+
|
|
41
|
+
> **Session-level behavior**: The goal keeps running until the condition is met or you run `/goal clear`. Run `/goal` (no arguments) to see stats like turns and tokens.
|
|
42
|
+
|
|
43
|
+
### Writing an Effective Condition
|
|
44
|
+
|
|
45
|
+
The [evaluator](#how-the-evaluator-works) judges the condition based solely on what CodeBuddy has **already expressed** in the conversation — it does not run commands or read files itself. So the condition should be phrased in a form that "CodeBuddy's own output can prove." "All tests in `test/auth` pass" works because CodeBuddy will run the tests itself, and the results will be in the transcript for the evaluator to read.
|
|
46
|
+
|
|
47
|
+
A condition that robustly supports multi-turn work typically includes:
|
|
48
|
+
|
|
49
|
+
- **A measurable end state**: test results, build exit codes, file counts, an empty queue…
|
|
50
|
+
- **A provable method**: e.g., ``\`npm test\` exits 0`` or ``\`git status\` is clean``
|
|
51
|
+
- **Inviolable constraints**: things that must not be changed along the way, e.g., "no other test file is modified"
|
|
52
|
+
|
|
53
|
+
The condition length limit is **4000 characters**.
|
|
54
|
+
|
|
55
|
+
If you want to set a fallback upper bound for the goal, add a turn/time clause to the condition, e.g., `or stop after 20 turns`. CodeBuddy will check progress against this clause each turn, and the evaluator can also read it from the conversation.
|
|
56
|
+
|
|
57
|
+
### Checking Status
|
|
58
|
+
|
|
59
|
+
Run `/goal` without arguments:
|
|
60
|
+
|
|
61
|
+
```text
|
|
62
|
+
/goal
|
|
63
|
+
```
|
|
64
|
+
|
|
65
|
+
In the TUI this opens a goal recap panel; in Web UI / ACP clients it opens an equivalent panel via ACP broadcast; in headless / SDK environments without a UI it falls back to plain text output.
|
|
66
|
+
|
|
67
|
+
Panel contents include:
|
|
68
|
+
- The condition
|
|
69
|
+
- Elapsed time
|
|
70
|
+
- Number of evaluated turns
|
|
71
|
+
- Token consumption (incremental during goal)
|
|
72
|
+
- The most recent reason from the evaluator
|
|
73
|
+
|
|
74
|
+
If there is no active goal but a goal was previously achieved in this session, the panel shows that goal's condition, duration, turn count, and token count.
|
|
75
|
+
|
|
76
|
+
### Clearing a Goal Early
|
|
77
|
+
|
|
78
|
+
```text
|
|
79
|
+
/goal clear
|
|
80
|
+
```
|
|
81
|
+
|
|
82
|
+
The following tokens are all treated as synonyms for `clear`: `stop`, `off`, `reset`, `none`, `cancel`. These are only recognized as clear commands on **exact single-token match** — `/goal stop using deprecated API` is still treated as "set a new condition" and won't be consumed.
|
|
83
|
+
|
|
84
|
+
Running `/clear` to restart the session also removes the active goal (hook unregistered + meta cleaned up).
|
|
85
|
+
|
|
86
|
+
### Resuming a Session with a Goal
|
|
87
|
+
|
|
88
|
+
When resuming a session via `--resume` / `--continue`, an unfinished goal is restored (both condition and scope are preserved).
|
|
89
|
+
|
|
90
|
+
> **Current limitation**: On resume, the original goal's createdAt / turnCount / token starting point are carried over — the timer and counters are not reset. If you want to "restart the clock," first run `/goal clear` and then `/goal <condition>` again. Goals that were already achieved or cleared will not be restored (meta has been deleted).
|
|
91
|
+
|
|
92
|
+
### Running in Non-Interactive Mode
|
|
93
|
+
|
|
94
|
+
`/goal` works in [non-interactive (headless) mode](./headless.md) and [Remote Control](./remote-control.md). In `-p` mode, setting a goal causes the evaluator loop to run until completion:
|
|
95
|
+
|
|
96
|
+
```bash
|
|
97
|
+
codebuddy -p "/goal CHANGELOG.md has an entry for every PR merged this week"
|
|
98
|
+
```
|
|
99
|
+
|
|
100
|
+
To terminate early before the condition is met, press `Ctrl+C`.
|
|
101
|
+
|
|
102
|
+
---
|
|
103
|
+
|
|
104
|
+
## How the Evaluator Works
|
|
105
|
+
|
|
106
|
+
`/goal` is a wrapper around a session-level [prompt-based Stop hook](./hooks.md). Whenever CodeBuddy's main agent finishes a turn, **the current condition + the current conversation** are sent together to the configured small-model evaluator. The evaluator returns a three-state result (yes / no / unreachable) with a short reason:
|
|
107
|
+
|
|
108
|
+
- **Yes (`ok: true`)**: Clears the goal, logs an "achieved" event, and the UI shows a `✔ Goal achieved` status bar.
|
|
109
|
+
- **No (`ok: false`)**: Injects the reason as an `isMeta=true` user message into the history (so the main model sees what to work on next), and lets CodeBuddy continue working. Also writes a `goal-progress` UI status bar: `◯ Goal not yet met… continuing`.
|
|
110
|
+
- **Unreachable (`ok: false, impossible: true`)**: Used when the evaluator determines that "this goal simply cannot be completed in the current session" (the condition is self-contradictory, required capabilities/resources are unavailable, or the model has exhausted reasonable attempts). The goal is immediately cleared, and the UI shows `✕ Goal could not be achieved`, preventing the loop from getting stuck.
|
|
111
|
+
|
|
112
|
+
The evaluator uses the small model bound to the **`lite` slot** in the product configuration (mapped to `gpt-5.1-codex-mini` / `gemini-2.5-flash` / DeepSeek `deepseek-v4-flash` etc. depending on the model provider). Evaluation only reads the existing transcript without invoking tools, so using a small model is both fast and cheap.
|
|
113
|
+
|
|
114
|
+
> **Billing**: Tokens consumed by the evaluator are billed to the small model account and are typically negligible compared to the main turn.
|
|
115
|
+
|
|
116
|
+
### Evaluation Window Constraint
|
|
117
|
+
|
|
118
|
+
To prevent "achieved immediately after setting" — where a previously achieved goal in the same session leaves a success response in the transcript — we inject the current goal's `createdAt` (ISO 8601) into the evaluator's user prompt with an explicit instruction:
|
|
119
|
+
|
|
120
|
+
> Evaluate ONLY the conversation that happened AFTER this timestamp. Earlier messages MUST NOT be used as evidence.
|
|
121
|
+
|
|
122
|
+
If no qualifying activity has occurred since the goal was set, the evaluator must return `{"ok": false, "reason": "Goal was just set; no work has been done yet against the new condition."}`.
|
|
123
|
+
|
|
124
|
+
### History Sanitization for the Evaluator
|
|
125
|
+
|
|
126
|
+
Before feeding history to the evaluator, we filter out the following extended item types (they are project-specific and unrecognized by the SDK):
|
|
127
|
+
|
|
128
|
+
- `goal-result` / `goal-progress` (goal's own UI status items)
|
|
129
|
+
- `summary` / `topic` / `ai-title` / `custom-title`
|
|
130
|
+
- `file-history-snapshot`
|
|
131
|
+
|
|
132
|
+
These items are neither user input nor assistant responses, have no value for the evaluator's judgment, and would trigger `Unknown item type` warnings from the SDK.
|
|
133
|
+
|
|
134
|
+
---
|
|
135
|
+
|
|
136
|
+
## Implementation Notes and Known Limitations
|
|
137
|
+
|
|
138
|
+
The following table summarizes key behaviors and known limitations of the current implementation for debugging reference:
|
|
139
|
+
|
|
140
|
+
| Behavior | Status | Notes |
|
|
141
|
+
| :--- | :--- | :--- |
|
|
142
|
+
| Set / replace / kick-off | ✅ | Immediately starts a turn after setting; auto-replaces when there's already an active goal |
|
|
143
|
+
| `/goal clear` aliases | ✅ | Supports five single-token synonyms: stop / off / reset / none / cancel |
|
|
144
|
+
| `/clear` also clears active goal | ✅ | Unregisters goal hook and cleans meta on session restart |
|
|
145
|
+
| Condition limit | ✅ | 4000 characters |
|
|
146
|
+
| Reason feedback into history | ✅ | Injection format: `Stop hook feedback: [<condition>]: <reason>` |
|
|
147
|
+
| Three-state semantics (ok / not-yet / impossible) | ✅ | Immediately clears goal on unreachable, preventing infinite loops |
|
|
148
|
+
| Evaluator uses small model | ✅ | Uses the model bound to `lite` slot (mapped per provider) |
|
|
149
|
+
| `/goal` no-arg → status view | ✅ | TUI / Web UI panel + headless text fallback |
|
|
150
|
+
| Persistent running indicator `⊚ /goal active (Xs)` | ✅ | Always visible at bottom-right of input box, 1Hz refresh |
|
|
151
|
+
| `--resume` turn / timer / token reset | ❌ Pending | Currently carries over original createdAt / turnCount; use `/goal clear` + re-set to restart |
|
|
152
|
+
|
|
153
|
+
---
|
|
154
|
+
|
|
155
|
+
## See Also
|
|
156
|
+
|
|
157
|
+
- [`/loop` for scheduled tasks](./scheduled-tasks.md#使用-loop-创建循环任务): Triggers repeatedly on a time interval, rather than until a condition is met
|
|
158
|
+
- [Hooks Guide](./hooks-guide.md) / [Hooks Reference](./hooks.md): Understand the underlying mechanism of prompt-based Stop hooks; write your own when you need more complex evaluation logic
|
|
159
|
+
- [Non-interactive (headless) mode](./headless.md): Run `/goal` in CI / scripts via `-p`
|
|
160
|
+
- [Remote Control](./remote-control.md): Trigger goals in Web UI / WeChat channels
|
|
161
|
+
- [Slash Commands Overview](./slash-commands.md): Index of all built-in slash commands
|
|
@@ -142,11 +142,13 @@ Besides shell commands (`type: "command"`), CodeBuddy Code also supports prompt-
|
|
|
142
142
|
|
|
143
143
|
> **Supported events**: Currently only `Stop`, `UserPromptSubmit`, and `PreToolUse` events are supported.
|
|
144
144
|
|
|
145
|
+
> **Session-level shortcut**: The built-in slash command [`/goal`](./goal.md) is a ready-to-use wrapper around prompt-based Stop hooks — simply type `/goal <condition>` to have CodeBuddy keep working until the condition is met, without writing hook configuration manually. If your evaluation logic can be expressed as a condition string, prefer `/goal`; only fall back to writing your own prompt hook when you need more complex prompt orchestration or cross-event coordination.
|
|
146
|
+
|
|
145
147
|
### How Prompt Hooks Work
|
|
146
148
|
|
|
147
149
|
Instead of running a bash command, the hook:
|
|
148
150
|
|
|
149
|
-
1. Sends the hook input plus your prompt to a fast
|
|
151
|
+
1. Sends the hook input plus your prompt to a fast small model (bound to the `lite` slot, mapped per model provider).
|
|
150
152
|
2. Receives a structured JSON decision.
|
|
151
153
|
3. Lets CodeBuddy Code enforce that decision.
|
|
152
154
|
|
|
@@ -201,7 +203,8 @@ The LLM must return JSON:
|
|
|
201
203
|
```jsonc
|
|
202
204
|
{
|
|
203
205
|
"ok": true | false,
|
|
204
|
-
"reason": "Explanation for the decision" // Required when ok is false
|
|
206
|
+
"reason": "Explanation for the decision", // Required when ok is false
|
|
207
|
+
"impossible": false // Optional, only effective for Stop events
|
|
205
208
|
}
|
|
206
209
|
```
|
|
207
210
|
|
|
@@ -209,6 +212,9 @@ The LLM must return JSON:
|
|
|
209
212
|
|
|
210
213
|
- `ok`: `true` to allow the operation, `false` to block it
|
|
211
214
|
- `reason`: Required when `ok` is `false`, explanation shown to CodeBuddy
|
|
215
|
+
- `impossible`: Optional boolean, only meaningful for `Stop` hooks. `{ok: false, impossible: true}` indicates that the evaluator has determined "this goal is fundamentally impossible to achieve within the current session" (contradictory conditions, unavailable resources, or the model has exhausted all reasonable attempts). CodeBuddy will stop looping and the UI displays a "cannot be achieved" terminal state. A plain `{ok: false}` still means "not yet achieved, keep working".
|
|
216
|
+
|
|
217
|
+
**`reason` injection into history semantics**: When a `Stop` hook returns `{ok: false}`, the `reason` text is not simply "shown to CodeBuddy" — it is injected as an internal user message with `isMeta=true` into the conversation history, so that the main model sees the evaluator's perspective in the next turn and can precisely address the outstanding gaps. This is the core mechanism that allows prompt-based Stop hooks to drive multi-turn iterative convergence (the `/goal` command relies on this pipeline under the hood).
|
|
212
218
|
|
|
213
219
|
### Example: Smart Stop Hook
|
|
214
220
|
|
|
@@ -360,6 +366,8 @@ Runs after the user submits a prompt but before CodeBuddy processes it. Useful f
|
|
|
360
366
|
|
|
361
367
|
Runs when the primary CodeBuddy agent finishes responding (skipped if the user manually interrupts).
|
|
362
368
|
|
|
369
|
+
> **Session-level shortcut**: The built-in slash command [`/goal`](./goal.md) is a wrapper around session-scoped prompt-based Stop hooks — `/goal <condition>` is all it takes to register a Stop hook that keeps CodeBuddy working until the condition is met, automatically handling three-state evaluation (achieved / not yet achieved, keep working / impossible to achieve), turn counting, token statistics, and `/resume` auto-recovery. When you need a session-level "keep working until X" behavior, prefer `/goal` instead of writing hook configuration manually.
|
|
370
|
+
|
|
363
371
|
### SubagentStop
|
|
364
372
|
|
|
365
373
|
Runs when a CodeBuddy sub-agent (Task tool) finishes.
|
|
@@ -287,6 +287,7 @@ Aligned with E2B process.proto, mapping gRPC methods to REST endpoints:
|
|
|
287
287
|
| GET | `/api/v1/plugins/marketplaces` | List configured plugin marketplaces |
|
|
288
288
|
| POST | `/api/v1/plugins/marketplaces` | Add plugin marketplace |
|
|
289
289
|
| POST | `/api/v1/plugins/marketplaces/browse` | Browse available plugins in marketplace |
|
|
290
|
+
| POST | `/api/v1/plugins/marketplaces/update` | Update marketplace (sync remote repository content) |
|
|
290
291
|
| DELETE | `/api/v1/plugins/marketplaces/:name` | Delete plugin marketplace |
|
|
291
292
|
|
|
292
293
|
### Settings Management
|
|
@@ -547,6 +548,11 @@ curl -X POST http://127.0.0.1:8080/api/v1/plugins/marketplaces/browse \
|
|
|
547
548
|
-H "Content-Type: application/json" \
|
|
548
549
|
-d '{"marketplace": "my-marketplace"}'
|
|
549
550
|
|
|
551
|
+
# Update marketplace (actually pulls latest content from remote)
|
|
552
|
+
curl -X POST http://127.0.0.1:8080/api/v1/plugins/marketplaces/update \
|
|
553
|
+
-H "Content-Type: application/json" \
|
|
554
|
+
-d '{"marketplace": "my-marketplace"}'
|
|
555
|
+
|
|
550
556
|
# Delete plugin marketplace
|
|
551
557
|
curl -X DELETE http://127.0.0.1:8080/api/v1/plugins/marketplaces/my-marketplace
|
|
552
558
|
```
|
|
@@ -42,7 +42,8 @@ Behavior description:
|
|
|
42
42
|
|
|
43
43
|
- CodeBuddy will scan lock files created by IDE plugins in the current user directory to detect available IDE instances
|
|
44
44
|
- Only considers an IDE as "valid" if its workspace contains the current directory
|
|
45
|
-
-
|
|
45
|
+
- Auto-connection only happens when **exactly one** valid IDE matches the current working directory; if zero or multiple match, auto-connection is silently skipped, and you can use `/ide` to manually select
|
|
46
|
+
- Stale lock files for IDE processes that have already exited are cleaned up before detection, avoiding connections to invalid ports
|
|
46
47
|
- After successful connection, the CLI will obtain from the IDE MCP server:
|
|
47
48
|
- File/diff preview (openFile / openDiff)
|
|
48
49
|
- Diagnostic information (getDiagnostics)
|