Introduction

The core philosophy of DeepSeek Harness (DSH) is “everything is a plugin.” When developing a Godot Web export locally, you typically need to open a terminal, run the build command, wait for it to finish, and then manually open a browser to debug. This fragmented workflow easily interrupts your train of thought. The dsh-godot-play plugin integrates building and playtesting into the DSH Web GUI, enabling one-click builds, zero external processes, and direct in-browser play.

Core Features

  • Web GUI panel: A floating “▶ Try Game” panel in the bottom-right corner of the browser, including a build button, status chip, and build log.
  • Host service injection: The host injects four services — webServer, subprocess, webRuntime, and workspaceRegistry — to run godot --headless --export-release directly and serve static files under a same-origin prefix.
  • Workspace gating: The entry button is shown only when the current workspace is a Godot project (containing project.godot); non-Godot workspaces collapse automatically.
  • Target follows the workspace: Build and hosting targets automatically follow the current DSH workspace, with no manual project selection required.
  • Multi-project support: Older clients fall back to a “Project” dropdown and manual registration.
  • Quick controls: Supports “↻ Restart” (reloads the iframe) and “Clear Log”.
  • Technical implementation: Pure DOM with zero framework dependencies; lazy-loaded iframe; tail-ring build log; idempotent install/uninstall scripts.

Prerequisites

  1. Godot is installed on your local machine, with the Web export templates installed.
  2. The target Godot project has a Web export preset (in the editor: Project → Export → Add… → Web, then save).

Installation and Enablement

Install using the official CLI:

dsh plugin --profile <profile> add dsh-godot-play

For local development, point directly to the repository directory:

dsh plugin --profile <profile> add /path/to/dsh-godot-play

Or run manually:

bash install.sh

Note: The desktop CLI requires you to fully quit the desktop app before running it, otherwise it may encounter a file lock. After installation, restart the corresponding dsh session for the changes to take effect.

Typical Usage

  1. Ensure the current DSH workspace is a Godot project; the “▶ Try Game” button appears in the bottom-right corner of the GUI.
  2. Click the button to open the panel, then click “🔄 Build and Load”.
  3. The status chip displays progress; expand “Log” to view Godot output.
  4. After a successful build, the iframe reloads automatically with a cache-busting timestamp, allowing you to play immediately.
  5. To restart the current game, click “↻ Restart” (only reloads the game); click “Clear Log” to clear the build log.

Configuration

The plugin is fully automatic by default. Configuration options are under config in cordis.patch.yml:
* projectRoot: If empty, follows the current workspace; if set, locks the target.
* godotBin: Automatically detects the environment variable or path.
* exportPreset: Automatically reads the first Web preset from export_presets.cfg.
* webRel: Explicitly overrides the output directory (by default, follows the Web preset’s export_path).
* workspaceGate: Controls whether the button is shown only when the workspace is a Godot project.
* allowRemote: Allows non-loopback remote access (must be used with trustedHosts).

Workspace Gating and Target Following

  • Gating logic: The browser-side component uses the host endpoint GET /api/godot-play/probe to determine whether the current workspace contains project.godot. If the host is not installed or unreachable, the button remains visible; if a non-Godot project is detected, the button is hidden.
  • Target following: The browser-side component reports the current workspace path to the host, and the host uses that path for building and serving. Switching workspaces switches the target. If projectRoot is set to lock the target, the panel displays a locked state and no longer follows.
  • Priority: Locked > Followed > Last selection (persisted) > Smart default.

Security and Cross-Origin

  • Security: Write operations are constrained by a trusted boundary (loopback or explicitly enabled allowRemote). There is no arbitrary command execution surface; argv is constructed with fixed arguments. Static hosting includes path traversal protection and only serves the current target export directory.
  • Cross-origin isolation: If Godot 4 Web export has threads enabled, the iframe must have cross-origin isolation (response header includes Cross-Origin-Embedder-Policy: require-corp). If the game fails to start, you can disable threads in the export preset or use window.__GODOT_PLAY_URL__ to inject an external hosting URL.

References