dsh-confirm-gate

dsh-confirm-gate Stops your AI agent before it rewrites 20 files and burns a day of budget. Install it and every action the model takes is counted. As the budget runs down it starts telling the model to brake; at the hard limit the model stops and waits for you to type confirm. No kernel changes, no required config.

English | 中文 · v0.3.0 What's new in v0.3.0

The gate now stays active under sandbox modes too. Previously it stepped aside in read-only and workspace-write, on the reasoning that a sandbox already bounds what the model can do. That reasoning covered *what* the model can touch, not *how many times* it touches it: 40 file edits inside a workspace-write session are still 40 edits, and still worth a nudge before the 41st.

So SANDBOX_MANAGED_MODES is now empty and the counter runs in every mode. The counter, the three reminder tiers, and the confirm release are all unchanged. If you relied on the old stepping-aside behaviour, set SANDBOX_MANAGED_MODES back to ['read-only', 'workspace-write'] in lib/index.js. Correctness fix only: the streaming mode-detection path now reads the mode on each call rather than caching it, so switching permission modes mid-session follows immediately. Plain language first

You just installed dsh. You have a very capable thing on your hands, and no steering wheel.

It works for a long time without saying anything, and you come back to find it went the wrong way. The same feature got written once last turn, then written again into a brand-new file this turn. You want it to continue, and you have no idea how far it got.

This plugin is the steering wheel. Reading is free. Opening files, searching code, listing directories never count. Only actions that change the world are counted. Every counted step comes with a message telling the model to come back and ask you. Hit the limit and it stops, waiting for your confirm.

No configuration needed. To make it looser or tighter, change two numbers. Even the confirmation word is yours to choose. The rest of this README is for people who want to know how it works. What it looks like while running

It is not an interceptor; it is a counter that talks. Every counted call comes with a message. The first 10 nudge the model to ask you; 11–14 escalate to an instruction to stop; only the 15th actually blocks the tool. That gap is what lets the model come to a halt while you are away from the keyboard. 30-second start

Restart DSH and it is on. To tune the budget, edit cordis.patch.yml: What it saves you This is not a security sandbox — sandboxing is DSH's own job. This manages cost and direction: it gives the model the ability to brake before it burns money or drifts. The details start here

A bounded-run framework that keeps an AI agent accountable on hosts where you had to grant full permissions. What — Per-turn counter for persistent operations. Gives the model a brake, not a wall. Verified — Live hot-switch on Windows (full → workspace-write → read-only → full), no restart. The model stopped itself at 11/15. Cost — ~$0.27 model spend. Zero external deps, ready-to-install archive in dist/. It steps aside under sandbox / read-only modes — complementary to DSH's own sandbox, not a replacement. It blocks mid-turn prompts on the WeChat channel — a turn-based channel cannot carry a mid-turn card; see section 9.

A runtime plugin for DeepSeek Harness. It keeps a per-turn counter of persistent operations, injects a stop instruction once the free budget is spent, and asks the user for confirmation at a hard limit. Compatibility — built and verified against DSH 0.2.0-rc.2; the peer range is >=0.2.0-rc.2, so it also loads on 0.2.1-rc.2 and later RC builds. If a future DSH release changes the tool-dispatch hooks this plugin binds to, it will fail loudly rather than silently — see §7. This is not a security boundary. It is a cost boundary and a course-correction mechanism. It assumes the agent is running without a sandbox holding the bound