How to use dsh-sandbox-escalation-fix
Dynamically hide invalid sandbox upgrade parameters based on session permissions to fix the repeated upgrade failure loop for OAI models under All Access.
This article is auto-derived from indexed fields (wiki / faq / compatibility_json), not freshly AI-generated.
This article is derived from the plugin's already-indexed fields (wiki / faq / compatibility_json / readme), not freshly generated by AI. Source field is noted at the end of each section.
Quick start
dsh-sandbox-escalation-fix
— source: plugin_wiki.wiki_content
Install & verify
dsh plugin --profile web add github:JUSTMONIKA2022/dsh-sandbox-escalation-fix
Run the command above in your DSH Web Profile. Then enable the plugin in the plugin list.
— source: plugins.install
Key points
- What It Does
- The Problem It Solves
- Before and After
- Why This Plugin
- This Plugin vs. Execution-Only Normalization
— source: plugin_wiki.readme_en (fallback readme_raw)
FAQ
Do I need to modify any configuration after installation?
No, the plugin is zero-config design. Just install it to the current DSH Profile and restart, it will automatically adjust the model-visible tool parameters according to the current Sandbox Mode and Approval Policy of each Session.
Will it modify DSH's security validation logic?
No. Strict widening checks, approval flows, and one-time authorization semantics remain unchanged. The plugin only does parameter projection and minimal compatibility processing on the model-visible side, and will not automatically approve any escalation requests.
What is the command to uninstall the plugin?
Execute dsh plugin --profile
What is the difference from the official DSH 0.1.1-rc.1 built-in approval=never runtime prompt?
The official version only partially improves error messages but still uses the same static escalation schema. The model may still see and fill in invalid escalation parameters. This plugin hides these fields at the schema level based on session state, and simultaneously cleans up escalation suggestions in descriptions and results.
When multiple Agents have different permissions, will they affect each other?
No. The plugin wraps independently by Agent Exact Scope. When Session A is read-only while Session B has full-danger access, the tool parameters each sees are calculated according to their own permission state, without mutual interference.
What to do when version error is reported on startup?
The @deepseek-ai/dsh-* packages within the Profile must maintain consistent versions and must belong to one of 0.1.0-rc.5, 0.1.0-rc.6, 0.1.0-rc.7, 0.1.0-rc.8, or 0.1.1-rc.1. Mixed or unknown versions will be rejected by the plugin at startup.
What if another plugin also wraps bash/pwsh/write/edit?
It depends on whether the other party implements the Symbol.for('dsh.tool-wrapper.v1') collaboration protocol. Those that implement it can collaborate in a priority chain; those that don't will have same-name tool registrations explicitly rejected, in which case one of the plugins needs to be uninstalled.
— source: plugin_wiki.faq_json
Compatibility
- DSH: 0.1.0-rc.5 / 0.1.0-rc.6 / 0.1.0-rc.7 / 0.1.0-rc.8 / 0.1.1-rc.1(必须保持一致)
- Node: ^22.19.0 || >=24.0.0
— source: plugin_wiki.compatibility_json
Pitfalls
Review the upstream repo before installing. This guide is auto-derived from indexed fields and may lag the latest release. If anything contradicts the official docs, treat the upstream source as authoritative.
— source: general rule