Introduction¶

When running local coding agents (Claude Code, Codex, OpenCode, ZCode, etc.) with DSH, common problems are “lack of visibility” and “unclear attribution”: which agent the task was assigned to, what the agent actually did, who produced the commit, and which step to accept. It is difficult to retrospect afterwards. Constrained by the local environment, most solutions either export data to the cloud or require writing scripts to stitch logs together.

The plugin introduced below, ningl32/agent-workbench, takes a different path: as a DSH client plugin, it puts local sessions, commits, and tasks from multiple agents into a single read-only observation panel, with data staying only on your machine. The README summarizes the core loop as See → Understand → Attribute → Accept. This article unfolds along this line of thought.

What is this¶

One-sentence positioning: A local-first DSH workspace plugin that turns your local AI coding agents into an “observable and accountable agent team.”

• Maintainer: ningl32 (GitHub repository ningL32/agent-workbench)
• Plugin name: fde-console, displayed as fde-console — Super Workbench in the README, package.json version 2.9.68
• License: MIT
• Category: Client (Community directory SkillHub)
• Stars: 0 (as of 2026-11-07)

There are several explicit design constraints that form its core value and prerequisites for installation:

1. Zero cloud dependencies, zero third-party runtime dependencies; only uses Node built-in modules (node:sqlite).
2. All data falls into an own directory (default ~/.dsh/fde-console/), data structure is data/ + config.
3. Read-only observation of agents; the workspace will not write into your agent process.
4. Credentials do not persist on disk: git credentials are obtained by reading git config at runtime, all output is redacted, and all outbound requests go through an SSRF whitelist.

Core Features¶

The README lists many capabilities; below are only a few directly related to daily use.

Task Panel. Kanban-style task management, with timeline, acceptor sign-off, deep links, priority, and deadlines; each task also has a daily diary.

Agent Observation. Adapts to local agents via six session sources, providing session lists, line-by-line transcript readers, running-now detection, and pagination by project; the panel allows viewing the dispatch prompt (original human instruction at startup) behind each session.

Submission Attribution. AI-generated commits can be automatically attached to tasks via three conventions: branch name task/<id>, commit message containing [#<id>], or binding the task to the project directory. The repository side has protection against cross-repository false positives. Details of the conventions are in docs/ATTRIBUTION.md, along with a snippet ready to paste into AGENTS.md and a commit-msg hook.

Evidence & Acceptance. Each task carries a timeline and session evidence; evidence is scored by task and supports one-click or batch confirmation. There is also an auto-generated daily/weekly report that can be exported to Markdown. Use Ctrl+K to perform global search across task titles, session titles, commit messages, and diaries.

Panel Views. Seven views in total: Overview, Task Radar (Meeting transcription → AI task breakdown → inbox gate), Task Board, Agents, Members, Team Activity (multi-source commit/PR stream + task attribution), and Settings.

Extension Interfaces. The MCP server exposes read-only tools via stdio (list tasks / search work / check agent status) for any MCP client to use. There are also outbound webhooks, Feishu/DingTalk bot notifications, and Gitea/GitHub/Gitee activity feeds. To connect sources not covered (like Cursor, Trae, Aider), you can write your own adapters following docs/ADAPTERS.md.

Heatmaps and Scorecards (28-day activity grid, SVG scorecard endpoint) also belong to the observation layer, suitable for team weekly meeting presentations.

Installation and Enabling¶

Environment Requirements¶

README explicitly lists:

• Node.js ≥ 22.13 (uses built-in node:sqlite)
• DSH 0.2.1-rc.2 (@deepseek-ai/dsh)
• pnpm in PATH (plugin installation forwards to it)

Installation Steps¶

First pitfall: The new profile defaults to only @deepseek-ai/dsh-base; the Web interface bundle is separate. Without this step, the plugin loads but does not activate; the log shows fde-console: pending (waiting for service: webServer), and the port is not listening. The command given in the README is as follows; note that the version number must align with your local dsh --version:

# 1. install / update the plugin into a profile (the profile is created on first use)
dsh plugin --profile fde-dev add <this repo path>

# 2. install / update the web surface bundle aligned with dsh version
dsh plugin --profile fde-dev add @deepseek-ai/dsh-web-app@0.2.1-rc.2   # ← use `dsh --version`

# 3. start (do not write dsh --profile fde-dev web, web is a reserved alias profile)
dsh --profile fde-dev --port 38082

The second pitfall is also in the README: if add @deepseek-ai/dsh-web-app@0.2.1-rc.2 is not pinned to a version, it will resolve to an incompatible old build, so the version number must be pinned.

After starting, open the printed URL (containing auth token); the sidebar will show Super Workbench. Local agents will be discovered automatically; you can see the first session with zero configuration.

Data Directory and Storage Migration¶

Data is located at <DSH_HOME|~/.dsh>/fde-console/. New data directories initially use JSON storage; to migrate your own unit to SQLite + WAL, run the migration script with all instances stopped:

node scripts/migrate-storage.js   # stop all instances first

JSON is still the export and interoperability format. The README also provides docs/VERIFY.md, which performs acceptance testing in the order: Test Threshold → Plugin Loading → API Round-trip → UI.

Trying out with Synthetic Data¶

Before officially connecting to agents, if you want to see a panel filled with data, you can inject a completely synthetic seed dataset (placeholder names, zero network requests):

node scripts/seed-demo.js                            # default data directory ~/.dsh/fde-console/data
node scripts/seed-demo.js --data-dir <dir> --force   # custom directory / overwrite

The seed script goes through the JSON storage channel, so it only accepts empty directories that haven’t been migrated; if the target is a migrated SQLite directory, the script will reject it and prompt you to use a new directory. To reset, simply delete the JSON files written by the seed.

Typical Usage¶

1. Implement attribution conventions in AGENTS.md. Paste the snippet from docs/ATTRIBUTION.md into the project so that agents produce commits with task/<id> branch names or [#<id>] in commit messages; commits will then automatically attach to the corresponding tasks, allowing direct acceptance in Team Activity.

2. Use the MCP server to let agents query the board. Add to the MCP client config:

{ "mcpServers": { "fde": { "command": "node", "args": ["<repo>/scripts/mcp-server.mjs"] } } }

This way, agents can query the task list, search for work items, and check agent status themselves, forming a bidirectional query between “task board ↔ agent”.

3. Run tests to keep a baseline. The command given in the README is npm test, i.e., node --test test/*.test.js, with 400+ test cases and zero network.

Suitable Scenarios and Notes¶

Who is it for? DSH users running multiple local coding agents simultaneously, needing task board management for progress and acceptance, and who do not want to send session data to the cloud; also suitable for teams wanting to create daily/weekly reports from agent activity.

Points that must be noted:

1. The plugin runs with the current dsh process permissions. Before installing, download and inspect the source code and license (MIT); confirm that cordis.patch.yml, plugin/, and scripts/ meet your security requirements.
2. The port is explicitly specified via --port (e.g., 38082), and the URL contains an auth token; do not expose it to the public network. Outbound requests go through an SSRF whitelist; ensure webhooks and IM notifications are pre-configured with the whitelist.
3. Both Node version and DSH version are strictly pinned (≥ 22.13, 0.2.1-rc.2 series); check the documentation under docs/ before upgrading; @deepseek-ai/dsh-web-app must be pinned to a version.
4. The stars count is 0 and the maintainer is a single person; this is an early personal project. It is recommended to run npm test and docs/VERIFY.md on a test profile before using it.

Conclusion¶

The value of ningl32/agent-workbench lies not in new concepts, but in converging the observation, submission attribution, acceptance, and reporting of local agents into a single read-only, local-first panel, without introducing third-party runtime dependencies. If you are already using DSH to run multiple local agents, it is worth trying out in a dedicated profile.

Directory page: https://www.skillhub.cn/plugins/ningL32/agent-workbench
GitHub: https://github.com/ningL32/agent-workbench