We ran 162 migration tests before calling our DSH Codex and Claude plugins usable

We use Codex and Claude Code to build Relay and its plugin repositories, so a one-prompt demo was not enough to decide whether the integrations were usable for real work. The two independently installable plugins are: - relay-dsh-plugin-codex: github.com/yangbobo2021/relay-dsh-plugin-codex - relay-dsh-plugin-claude: github.com/yangbobo2021/relay-dsh-plugin-claude Both add a native conversation backend to official DeepSeek Harness without patching DSH core or requiring a Relay checkout. We split the workflows we actually use into 162 atomic requirements: 76 for Codex and 86 for Claude. The matrix covers conversation continuity, images and files, shell and code tools, tests and Git, Skills, MCP, project configuration, permissions, environment handling, session import, restarts, and long-context continuation. The August 29 snapshot was: - Codex: 59 supported, 6 partial, 11 unsupported - Claude: 78 supported, 3 partial, 5 unsupported The useful part was not the score. The failures showed cases where DSH displayed an image that Codex never received, an interrupted task still wrote a delayed file, sensitive values persisted outside the visible chat, and an existing native session could not be carried into the plugin. Those results directly drove the next day's Codex 0.1.3 and Claude 0.1.4 releases. We fixed the reproducible paths, kept the unresolved cases visible, and will publish a new matrix after the complete suite runs again. Validation evidence: - Codex: github.com/yangbobo2021/relay-dsh-plugi...ain/validation/migration-compatibility - Claude: github.com/yangbobo2021/relay-dsh-plugi...ain/validation/migration-compatibility This is the loop we want to keep: use the plugins on real projects, reduce failures to repeatable cases, repair the boundary, rerun, and retain what still does not work. For an agent-backend migration, which capability would you treat as release-blocking even if normal chat and coding already work?