Mirage for DeepSeek Harness
An agent that works through a local shell usually sees whatever the host filesystem and command environment expose. Mirage changes that boundary. The mirage DeepSeek Harness plugin replaces DSH's normal filesystem and shell providers with a virtual workspace backed by selected mounts. Cloud storage, messages, databases, and local resources can appear under one file-like tree, while a policy decides what the agent may read, write, execute, or even see.
Swapping Out DSH's Filesystem and Shell for a Virtual Workspace
Plugin quick facts
| Item | Detail |
|---|---|
| Package | @struktoai/mirage-dsh |
| Publisher | Strukto AI |
| Provider change | Replaces the DSH filesystem and shell surfaces in its profile |
| Visibility | Host paths stay absent unless deliberately mounted |
| Policy | Mount modes plus allow, ask, deny, show, and hide rules |
| Node requirements | Plugin package: >=20.10.0; full DSH workspace: ^22.19.0 or >=24.0.0 |
| Documentation reviewed | September 16, 2026 |
Setup and first check
Create a separate profile before replacing the normal filesystem and shell providers:
dsh plugin --profile web add @struktoai/mirage-dsh
dsh --profile web --dump-configBegin with a RAM-backed temporary mount and one read-only service. Confirm that an unmounted host path is invisible, a denied operation remains blocked, and an ask rule reaches the DSH approval channel. Add production credentials or writable mounts only after those boundaries behave as intended.
Treat the DeepSeek Harness host as developer-preview software and retest mounts, approvals, and policy routing after an upgrade.
The DSH bundle disables the standard filesystem and bash sandbox providers, then inserts Mirage-backed implementations for the same ctx.fs and ctx.shell seams. DSH file tools and shell commands therefore operate inside the configured virtual workspace rather than directly on the host disk.
That swap changes several assumptions:
- A host path is not automatically present in the virtual tree.
- The session working directory resolves to a workspace location, not an arbitrary host directory.
- Search happens through commands available inside the workspace rather than through a host-side search process.
- PowerShell and host-subprocess search surfaces are disabled by the supplied bundle configuration.
- A mounted resource can have a narrower mode than the service account behind it.
The default example starts with an executable RAM-backed /tmp mount. Real usage requires an explicit profile configuration for every additional resource. If the task is ordinary repository editing on a trusted local checkout, the native DSH filesystem may be simpler. Mirage becomes more interesting when the task crosses several remote systems or needs a workspace boundary that is independent of the host disk.
Mounting S3, Redis, Slack, Gmail, Notion, and Postgres as Files
Mirage presents different services through shared filesystem semantics. S3 objects, Redis data, Slack content, Gmail messages, Notion pages, and Postgres data can occupy separate mount paths. An agent can then use familiar operations such as listing, finding, reading, filtering, copying, or writing, subject to each resource adapter and its mode.
This does not make unlike services identical. A Slack message is still a message, a database row is still structured data, and an object store still has object-store behavior. The file-like interface gives the agent one navigation model while each adapter translates operations into the service's actual capabilities.
Choose mount names that reveal the boundary and account, for example:
/source-s3
/support-slack
/staging-redis
/product-notion
/analytics-postgresAvoid vague names such as /data when several credentials or environments are involved. Separate production and staging resources even when they use the same adapter. A useful first workflow is read-only: locate an incident identifier across messages and logs, assemble a report in RAM, and stop before sending or writing anything back.
Virtualized command-line tools can also expose service operations by name. That can be convenient for an agent that already understands shell pipelines, but it increases the importance of command-level permissions. A familiar command shape should not be treated as proof that the underlying action is harmless.
Per-Mount Permissions and Sandbox Routing, Explained
Mount mode is the first boundary. A resource can be configured for read, write, or execution behavior appropriate to its adapter. The profile then adds command rules using allow, ask, and deny. File visibility uses show and hide, so a hidden path is absent from the agent's view rather than merely returning a read error.
An ask rule routes the proposed action through DSH's approval channel. Rejection, dismissal, or an unanswered request prevents the action from running. The approval prompt should still be read carefully, especially when a command includes generated paths, message text, or query parameters.
Use layered controls:
- Give the mounted service account the narrowest external permissions.
- Mount only the required resource and environment.
- Set the smallest useful mount mode.
- Deny publication, deletion, and production mutation by default.
- Require a human decision for the remaining high-impact commands.
- Keep temporary outputs in a separate RAM mount.
Read-only DSH mode narrows Mirage mount grants to read behavior. That is helpful for investigation, but it does not decide whether the content is appropriate to send to the model. Secrets, private messages, and regulated records require an access decision before they enter the workspace at all.
Runtime Requirements and Where Mirage Doesn't Fit
The @struktoai/mirage-dsh package itself declares Node.js >=20.10.0. That is not the requirement for a complete DeepSeek Harness environment: the current DSH workspace declares Node.js ^22.19.0 or >=24.0.0. The host environment must satisfy the higher DSH requirement. Mirage also pins its DSH filesystem, shell, and spill peer packages to 0.1.5-rc.2, so test it with that matched package set instead of assuming compatibility across harness upgrades.
Install the bundle into an evaluation profile, then provide the mounts and policy in that profile's own configuration:
dsh plugin --profile web add @struktoai/mirage-dshMirage is a poor fit when a task depends on unmounted host tools, a native PowerShell workflow, a host-side search plugin, or direct editing of a local repository that has not been represented inside the virtual workspace. It also adds configuration work for credentials, adapters, modes, runtime routing, and approvals.
Test one bounded task before moving a larger workflow. Confirm that hidden resources are absent, denied commands fail, approval requests reach the intended human, and outputs land only in the expected mount. Roll back to the standard DSH providers when the virtual boundary adds more friction than control.
Frequently Asked Questions
Does Mirage copy every connected service into one local folder?
No. It exposes configured resources through a shared virtual filesystem interface. The adapters still operate against their underlying services, and each mount keeps its own credentials and permission mode.
Can the agent still access the host filesystem?
Not through the replaced DSH filesystem and shell providers unless a host resource is deliberately mounted. Host paths and the session's original working directory do not automatically exist inside the virtual workspace.
What do allow, ask, and deny control?
They control command and CLI execution within a Mirage profile. Ask routes a proposed action to the DSH approval channel, while deny blocks it and allow permits it within the remaining mount and service boundaries.
Is Mirage the right choice for ordinary local code editing?
Not necessarily. The native DSH filesystem is simpler when the task stays in one trusted local repository. Mirage is more relevant when several services need one controlled interface or when host-disk access should be replaced with explicit mounts.
Decide Whether Virtualization Belongs in Your Verdent Workflow
Create one evaluation profile with a RAM mount and one read-only service. Test discovery, a denied write, and an approval-gated action before adding more systems. Read the Verdent quick start to weigh that control against setup complexity and the simpler local-filesystem path.