mirror of
https://github.com/deepseek-ai/deepseek-harness
synced 2026-08-15 21:04:50 +00:00
5cf5e0cb76
Deleting the preset a user default names left the setting pointed at an id nothing will ever supply again, and every session created without an explicit pick then failed to start — the delete dialog called it 'new sessions cannot select it', which understates a hard creation error. `remove` now clears the user layer when it named the preset just deleted, exposing the deployment's own default underneath. Storing a default that does not exist YET stays deliberate: the roster is a live directory, so a name absent now may exist by the time a session asks, and `resolve` still reports that case. `agentPreset.select` also leaves the loopback set. It was pinned as a real escalation — one preset mounts the toolset that edits the live runtime — but `session.create` already takes an `agentPreset`, so pinning only the switch left the same capability one method over. The deeper reason is that the capability is not the preset's to grant: the deployment's own default already carries `bash` and the filesystem tools, so any caller that may start a session at all can already run commands as this process. `read`/`write`/`remove` stay pinned on their own footing — those touch files, not sessions.
20 lines
441 B
JSON
20 lines
441 B
JSON
{
|
|
"version": "0.0.1",
|
|
"configurations": [
|
|
{
|
|
"name": "dsh-web",
|
|
"runtimeExecutable": "env",
|
|
"runtimeArgs": [
|
|
"DSH_HOME=/Users/jyc/projects/agentProjects/deepseek-harness/.claude/worktrees/tool-call-side-effects-fix-680343/tmp/dsh_home",
|
|
"DSH_TELEMETRY_DISABLED=1",
|
|
"node",
|
|
"apps/cli/lib/bin.js",
|
|
"web",
|
|
"--port",
|
|
"3080"
|
|
],
|
|
"port": 3080
|
|
}
|
|
]
|
|
}
|