gameEval lets the in-app assistant (and MCP) run Lua in the running game through the bridge (cmd.eval). Today it is read-only by convention only: the tool description and system prompt tell the model to inspect and never mutate, but nothing enforces it, and the mod runs whatever Lua arrives. That is acceptable for a local single-player game (worst case is reloading a save), but it means the agent cannot safely use eval for write actions.
Proposal: add a propose-then-apply approval gate, like the block and plan drafts. When the assistant wants to run a Lua snippet, surface it in the chat UI for the user to review and Apply or Reject before it executes, rather than running autonomously mid tool-loop. That makes "the player is in control" actually true, and would let the agent safely take in-game write actions (set research, place blueprints, fix state) with explicit per-call consent.
Pieces:
- A draft-style return from the eval tool that does not execute server-side; the model proposes the Lua instead of running it.
- Chat-UI rendering of the proposed Lua plus an Apply action that sends
cmd.eval over the bridge and shows the result.
- A mod-setting kill switch (
pyops-allow-eval, default on) as defense in depth.
The read-only convention is acceptable for now, so this is deferred until the agent needs to take in-game write actions.
gameEvallets the in-app assistant (and MCP) run Lua in the running game through the bridge (cmd.eval). Today it is read-only by convention only: the tool description and system prompt tell the model to inspect and never mutate, but nothing enforces it, and the mod runs whatever Lua arrives. That is acceptable for a local single-player game (worst case is reloading a save), but it means the agent cannot safely use eval for write actions.Proposal: add a propose-then-apply approval gate, like the block and plan drafts. When the assistant wants to run a Lua snippet, surface it in the chat UI for the user to review and Apply or Reject before it executes, rather than running autonomously mid tool-loop. That makes "the player is in control" actually true, and would let the agent safely take in-game write actions (set research, place blueprints, fix state) with explicit per-call consent.
Pieces:
cmd.evalover the bridge and shows the result.pyops-allow-eval, default on) as defense in depth.The read-only convention is acceptable for now, so this is deferred until the agent needs to take in-game write actions.