DSH plugin task queue: dsh bot approval and execution

A task handled by a DSH plugin can look ignored when it is actually queued, paused or waiting for a person, and that difference matters before any setting changes. The path from enqueue to execution crosses a concurrency limit and an approval gate, and each stage leaves different evidence. Reading the evidence in order is faster than guessing about model speed.

Enqueue creates the dsh plugin task record

The first action after a request is a record, not a model call, and a task without a record does not exist yet.

When a user hands work to the bot, the DSH plugin creates a record before it calls a model. That record carries the requester, the goal, the tools the task expects, the working directory and a creation time. Every later state change attaches to this record, which makes it the first thing to look for when nothing seems to happen. If the bridge that delivers the message fails, the chat shows a delivered message and the task list shows nothing at all.

A missing record points to the submission stage rather than the queue. A record that exists but never changes state points to scheduling, concurrency or a stalled predecessor. Checking the installed plugin version against its DSH Plugin Hub entry prevents debugging a path that the current release no longer uses. Getting this distinction right early saves a long detour through logs that never had a task to report.

Concurrency decides when a DSH plugin task starts

The scheduler weighs concurrency quota, task type and unfinished predecessors, so a short queue can still be a slow queue.

Read tasks can usually run in parallel, while write tasks that touch the same files should run alone. The scheduler does not judge whether two writes conflict; it only follows the limits it was given. A queue length that keeps growing usually means a stuck task or a quota set too low, not a slow model. State distribution is a better health signal than the number of waiting tasks.

Waiting tasks still occupy a slot, so an approval with no timeout can block the queue behind it. Bounding retries matters for the same reason, especially when a failed write already produced partial effects. An idempotency check before a retry is cheaper than cleaning up duplicates afterward. Concurrency that matches task behavior is easier to explain to a team than a single high number.

The approval gate pauses an out-of-bounds dsh plugin task

Approval is the brake between automation and damage, and the gate pauses a task when it reaches outside its permitted world.

The gate typically triggers on paths outside the workspace, shell commands and network destinations that were not allowed. When it pauses, it should show the tool name and the full arguments, because a partial view turns confirmation into a blind signature. Approving without seeing the target is worse than denying, since it teaches the operator to click through future prompts.

The workspace is the first boundary, and a bot confined to a project subdirectory avoids most accidental writes before the gate is even reached. Relying on the model to respect directory conventions is not a boundary, because the model does not know them. Many DSH plugins expose the tool allowlist per task, and a narrower list reduces prompts rather than increasing friction, since fewer tools can reach the gate at all. Network rules deserve their own allowlist by domain, and the request target should be visible in the approval record for later audit.

Execution depends on the DeepSeek Harness plugin runner

A background executor extends how long a task lives, not how far it may reach.

Without a background executor, a task runs only inside the current session and stops when the session closes. With one enabled, the task continues in a separate process and should write its own log. The common mistake is assuming that the runner inherits every restriction from the session, when its identity and working directory need separate confirmation. An executor that is not enabled looks exactly like a queue that never moves, which is why the two should be checked separately.

If a DeepSeek Harness plugin runner uses an overly privileged account, the approval gate loses much of its effect, because the process can already touch more than the workspace allows. Leftover processes after a finished task hold concurrency slots and can feed stale context into the next run. Confirming process exit and sealing the log is part of execution, not an afterthought. The executor's log is also the only place where a silent failure leaves a trace.

Diagnosing a stuck dsh plugin task

A blocked task and a stuck task look alike from the outside, but they call for opposite responses.

A blocked task has an approval prompt and is waiting for a decision, so the response is to confirm or narrow the permission. A stuck task has no prompt and no progress, which points to the executor, the queue or a dead predecessor. Overreach denials leave records that point at the workspace or allowlist, while silent failures live at the end of the executor log.

1. Confirm that the task record exists and note its current state.
2. Check whether the executor process is running and which system user owns it.
3. Compare the executor working directory with the bot configuration.
4. Read the executor log and find the last successful call before the error.
5. Close the session, trigger the same task again and see whether it continues.

Repeating the same task after a fix is the only proof that the chain works, because a repaired stage can still hide a second problem downstream. If the same symptom returns, the configuration is a better suspect than the task itself. Automation stays safe when permissions shrink as tasks grow, not when the gate is removed to make the queue move.

Sources: dsh-bot plugin entry, plugins and lifecycle, sandbox.