Smalldy/godot-bridge
godot-bridge
DSH (DeepSeek Harness) plugin that launches and drives a running Godot 4.x game through its in-game TCP interaction server — replaces the godot-mcp MCP server with native agent tools.
Install
npx @deepseek-ai/dsh plugin --profile web add github:Smalldy/godot-bridgeRestart `dsh web` after install. Bundle APIs can change during the developer preview.
README badge
[](https://dshhub.dev/plugins/godot-bridge)Paste this into your README. The star count updates with every catalog sync.
From the README
Excerpt from Smalldy/godot-bridge, cleaned of badges and images.
English | 中文
godot-bridge
Native DeepSeek Harness (DSH) plugin that launches and drives a running Godot 4.x game through its in-game TCP interaction server — replacing the godot-mcp MCP server with first-class agent tools.
No MCP protocol, no Python server, no editor addon. The game side is untouched: McpInteractionServer (the mcp_interaction_server.gd autoload) already listens on 127.0.0.1:9090 and speaks newline-delimited JSON — godot-bridge speaks the same protocol natively from inside the DSH host.
Tools
godot_run_project starts without the local debugger (-d) by default, so godot_command eval works normally. debug:true is diagnostic mode: the instance runs with the local debugger, the interaction server refuses eval (it learns this from the GODOT_BRIDGE_DEBUGGER=1 environment variable the bridge sets at spawn — Godot consumes -d before OS.get_cmdline_args() can see it, measured on 4.7.2, so an argv check alone never fires) (a syntax error would otherwise enter the interactive debug> prompt and deadlock, issue #13), and a script error returns a debuggerTrace (break reason, *Frame N stack frames with file:line, ≤4 KB raw tail) plus a next step and ends that run. In diagnostic mode the bridge watches stdout for the debugger and writes exactly one quit (never continue), then classifies the outcome by exit code: exit 0 → diagnosis: "debugger-quit"; any non-zero code → diagnosis: "debugger-trap" with exitCode and crash: true; still running after 3 s → debugger-trap with killed: true. The classification is deliberately honest: on Godot 4.7.2-stable win64 writing quit exits in ~38 ms with 3221225477 (0xC0000005, ACCESS_VIOLATION) and a C++ backtrace, so that run is reported as a crash trap, not as a graceful exit. Measured regression baseline (minimal project + syntax-error script): without -d the process exits in ~372 ms with SCRIPT ERROR … at: GDScript::reload; with -d and stdin at EOF it prints 12089 Debugger Break/debug> lines in 3 s (1.78 MB, ~590 KB/s) and must be killed — the issue #13 loop; with -d and a stdin pipe only one break/prompt appears (2.4 KB) because the debugger waits for input. To run code under the debugger, use godot_run_headless --script.
…
