@kuun993/dsh-loop-engine

Configuration

1. Build the plugin:

   pnpm install && pnpm run build
   

2. Add the dependency in $DSH_HOME/profiles/web/package.json:

   "dependencies": {
     "@kuun993/dsh-loop-engine": "1.0.0-rc1",
     "...keep existing deps"
   }
   

   The package is published on npm as @kuun993/dsh-loop-engine. For local development, use a file: reference to your checkout instead of the version string.

3. Append one composition row in $DSH_HOME/profiles/web/cordis.patch.yml:

   - insert:
       - id: loop-engine
         name: '@kuun993/dsh-loop-engine'
   

4. Install and restart:

   cd $DSH_HOME/profiles/web && pnpm install
   

   Restart dsh web once so the plugin is picked up.

Switching engines rewrites a small managed block in cordis.patch.yml. Everything else you wrote in that file is preserved; only the plugin's own span changes.

Usage

1. Open Settings → Loop engine.
2. Choose an engine:
   • In-process (default) — the built-in loop driver;
   • Claude Code CLI — the Claude Code driver;
   • Codex CLI — the OpenAI Codex driver.
3. Switching between these applies after restarting dsh web. To return to the default, pick In-process and restart again.
4. To remove the plugin: delete the loop-engine row from cordis.patch.yml, drop the dependency from package.json, then pnpm install and restart dsh web.

Codex engine details

The driver bypasses the @openai/codex-sdk (which only exposes whole-item output) and spawns codex app-server as a child process, speaking JSON-RPC over stdio. The app-server streams token-level deltas via item/agentMessage/delta and item/reasoning/summaryTextDelta, so thinking and replies paint progressively in the session — like the Claude Code engine.

• Streaming. Reasoning deltas and agent-message deltas are forwarded live as assistant/chunk events; durable messages land at the correct step boundaries with usage attached on turn completion.
• Skills. The Codex engine registers a skill provider that surfaces AGENTS.md (project root and ~/.codex/AGENTS.md) through the same dsh skill-injection seam as Claude skills.
• No interactive tool approval. Permissions are the declarative sandboxMode + approvalPolicy pair resolved per query from the session's permission knobs (or pinned via the plugin's sandboxMode/approvalPolicy config). A session ask policy maps to on-request, whose CLI prompt degrades to a denial in the unattended dsh runtime.
• No dsh subprocess sandbox integration. The driver spawns codex app-server itself; the dsh subprocess service (and its sandbox) does not wrap it.
• No engine-specific slash commands are registered for Codex in this version.