Skip to main content

Debug and package

Debug step by step on your computer​

After you install a personal workflow plugin, type / in a chat and choose Debug plugin, or select the plugin and choose Debug step by step. The debug card appears in the current chat. It doesn't create a task, a second chat or a separate window.

  1. Confirm the plugin, version, public inputs and debug notes. You can bring in the chat's text, earlier attachments, and screenshots or files waiting to be sent.
  2. The debug run executes nodes in dependency order on your local runner. Each node can use a different supported local harness (runtime) and model.
  3. The agent's replies and tool calls appear in the chat. File and decision outputs are checked one by one, and their SHA-256 is checked again at each hand-off.
  4. An approval card can open the checked files. Markdown, text, JSON and CSV preview in the card; other files open in the system's default app.
  5. A human_review step needs explicit confirmation from the chat's owner. If it's not confirmed, failed, or the connection state is unknown, later steps and queued messages don't proceed.

Also:

  • Retry applies only to the failed node, within its retry limit. Stopping requires first confirming the runner's state.
  • After a refresh, you can reopen the debug card. After the client restarts, resume it explicitly; finished nodes are not sent again.
  • Working files go to plugin-debug/<runId>/<node>-<attempt>. A local publish step only marks the debug run finished; nothing is uploaded to the organization.

The debug run uses your model authorization, device authorization and Skill policy. Each node can reach only its declared MCP subset.

What local debugging doesn't do​

  • It doesn't change how the Hub runs organization workflows.
  • It doesn't run steps that need hosted or remote runner routes locally.
  • Code review pinned to a Git commit needs the organization's code workflow. Local debugging blocks it instead of pretending it passed.
  • Custom HTML UI resources are not mounted automatically. Script and deploy nodes outside the editor are not executed.

Passing a local debug run doesn't mean the plugin has been published to your organization.

Package​

Put plugin.json, an optional workflow.json, Skills and other files at the package root, then zip:

my-team-flow.soduwork-plugin
├─ plugin.json
├─ workflow.json          # optional
├─ skills/                # optional
└─ README.md              # optional

See Package format for the format and size limits.

The client can also export an installed plugin. The portable export includes every bundled file with its checksum, so importing it on another computer doesn't depend on your local paths.

Import from other tools​

SoduWork reads .codex-plugin/plugin.json and .claude-plugin/plugin.json and converts them to an immutable SoduWork package.

  • Instructions, Skills, agents and workflows that can be mapped appear in the capability report.
  • Hooks, arbitrary binaries and other parts that can't be expressed safely are not run. They appear as adapter warnings or blockers.

A successful import doesn't mean every behavior of the original plugin is supported. Read the pre-check report and run a simulation before you use it.

harness harnesses runtime runtimes 底座
Edit this page