Introduction¶
The design philosophy of DeepSeek Harness (DSH) is “everything is a plugin.” When developing agent tools, you often encounter scenarios that require privilege escalation, such as escalating sandbox permissions from the default level to danger-full-access. This escalation typically requires manual confirmation in an approval dialog. If you need to test or debug repeatedly, confirming every request can reduce efficiency.
dsh-session-allow is a DSH Web GUI plugin that adds an “Allow for this session” option to the approval dialog. Once a developer clicks it, the mode is authorized for the current session, and subsequent identical requests will pass automatically without showing the dialog again.
Features¶
The plugin implements this behavior by replacing the DSH core approval panel, without modifying the core package.
- New option: The approval dialog shows an “Allow for this session” option (alongside “Deny” and “Allow once”).
- Automatic approval: Once a mode is granted, subsequent requests for that mode in the current session are approved automatically, and the dialog no longer appears.
- Mode isolation: Only requests that match an already granted mode are approved automatically; other modes still trigger the normal prompt.
- Revocable: The bottom of the dialog displays the list of modes granted for the current session (as chips). Click × to revoke the authorization.
- Session isolation: After refreshing the page or starting a new session, previous authorization records are automatically cleared and the permission state is reset.
Installation and Activation¶
Install the plugin with the following command. After installation, restart dsh web to load the new component.
dsh plugin --profile web add https://github.com/AnakinCao/dsh-session-allow.git
Note: Choose one installation method, do not mount it repeatedly.
How It Works¶
The plugin works by overriding the conversation.composer slot.
- Registration priority: The DSH core approval panel registers at priority 1 in the
conversation.composerslot. This plugin registers the same selector at priority 0. According to the slot mechanism, the priority 0 component fully replaces the priority 1 component. - Data storage: Authorization records are stored in
localStorage['dsh.sessionAllow.v1']. - Authorization key: The system parses the request reason (usually
escalate sandbox to <mode>: ...), extracts the mode as the authorization key (mode:<mode>). Non-escalation requests usetool:<tool>:<reason>as the key. - Network communication: Matching requests are automatically answered as
allowed-onceon the network, but the host audit log still recordsapproval/askedandapproval/decided.
Typical Usage¶
Scenario 1: First request for a dangerous mode
The tool requests privilege escalation to danger-full-access. The dialog displays:
* Deny
* Allow once
* Allow for this session: danger-full-access
Scenario 2: Grant authorization
Click “Allow for this session: danger-full-access”. The current request is allowed, and the mode is authorized for the current session.
Scenario 3: Repeated request
Request danger-full-access again in the same session. The dialog no longer appears; the system silently approves the request automatically.
Scenario 4: Request a different mode
Request a mode that has not been granted yet in the same session (for example, tool:web-search). The dialog appears normally and prompts the user for approval.
Scenario 5: Revoke authorization
At the bottom of the dialog, you can see chips for modes granted in the current session. Click the × on a chip to revoke that mode. The dialog will appear again for the next request.
Uninstallation and Cleanup¶
dsh plugin --profile web remove dsh-session-allow
If you want to manually clean up authorization data, delete localStorage['dsh.sessionAllow.v1'] in the browser developer tools console.
File Structure¶
dsh-session-allow/
├── package.json # 插件声明
├── cordis.patch.yml # 加载器注册入口
├── lib/
│ ├── index.js # 主机端占位符插件
│ └── client.js # 客户端包(接管面板 + 会话授权)
├── test/
│ └── behavior.test.mjs # 授权、自动批准、撤销的回归测试
└── README.md