WIP checkpoint: Address review feedback: Research and design GDScript sandboxing approach

Verified all three options from the task against Godot 4.6.2 directly
(godot --headless), rather than trusting the probe scripts' own printed
output from earlier sessions:
- ScriptServer doesn't exist as a class; no disable_os/disable_file_access/
  disable_network project settings exist either. Nothing to configure.
- SubViewport isolates rendering/input only, not script capabilities — a
  script inside one has identical OS/FileAccess/network access.
- Expression is not safe by default (can still reach unsafe methods through
  a base instance); blocklisting dangerous substrings is trivially bypassed.

Recommendation: don't sandbox GDScript in-process (nothing to sandbox
with) — use a narrow non-Turing-complete content DSL for the common case,
and OS-level process isolation only if genuinely general scripting turns
out to be required.

docs/architecture/editor.md

@@ -1,369 +0,0 @@
-# Editor Architecture: Godot Editor Plugin vs. In-Game Editor
-
-> **Status:** Proposed
-> **Owner:** Platform team
-> **Related:** World chunk data format & persistence, server authority + client
-> prediction, content moderation & age verification, avatar component system
-> **Godot version:** 4.6.2 stable
-
-## 1. Overview
-
-This document evaluates the two primary ways to build the **world/level
-authoring tool** for **agp-game**:
-
-- **(a) Godot editor plugin** — extend the Godot editor itself with custom
-  panels, dock widgets, and tools that operate on the project's scenes and
-  resources.
-- **(b) In-game editor** — a fully custom editor built as game UI (Godot
-  `Control` nodes) that runs inside the running game, editing the game's own
-  world data.
-
-The goal is to pick the approach that best fits the platform's constraints:
-a **server-authoritative** multiplayer game where the **world is stored as
-versioned chunks** (see `world.md`), content is **moderation-flagged** (see
-`content_moderation.md`), and the client is a **shipped binary** that players
-run (not a dev tool).
-
-This document is a **decision record**: it lays out the trade-offs, gives a
-clear recommendation, and defines the resulting architecture boundaries.
-
----
-
-## 2. Context & Constraints
-
-Before comparing the two approaches, we must fix the constraints that drive the
-decision. These come from the existing architecture docs.
-
-### 2.1 The World Is Data, Not Scenes
-
-`world.md` defines the world as **chunk data** (JSON for authoring, binary for
-runtime/network), persisted in SQLite on the server. A chunk is the atomic unit
-of load, save, and stream. The **server is the only writer** to the store;
-clients submit **deltas** against a `base_revision` and the server validates and
-applies them.
-
-**Implication:** The editor's output is **chunk payloads**, not `.tscn` scene
-files. Whatever editor we build must serialize to the chunk contract, not to
-Godot scene resources.
-
-### 2.2 Server-Authoritative & Moderation-Aware
-
-- The server validates every edit (schema, bounds, moderation) before
-  persisting (`world.md` §5.4).
-- Content carries **content flags** aggregated from referenced assets/scripts
-  (`content_moderation.md` §3). Mature content is gated behind age verification.
-- The client receives a **content manifest** and never loads content not in it.
-
-**Implication:** An editor that runs on a **player's machine** cannot be the
-authority on what gets published. Editing must go through the server's
-validation pipeline, and the editor must surface moderation flags.
-
-### 2.3 The Client Is a Shipped Binary
-
-The game is a multiplayer product. Players run a **release build**. The Godot
-editor is a **development tool** that players do not have.
-
-**Implication:** If authoring is a first-class *player* feature (user-generated
-content), the editor must ship inside the game binary. If authoring is a
-*developer/platform* feature, it can live in the editor.
-
-### 2.4 Two Distinct Audiences
-
-The evaluation must separate two audiences, because they have opposite needs:
-
-| Audience | Who | Where they run | What they build |
-|----------|-----|----------------|-----------------|
-| **Platform/dev** | The team building the game | Godot editor (dev machines) | Base worlds, rooms, templates, test levels |
-| **Players (UGC)** | End users | The shipped game | Their own rooms/worlds, published to the server |
-
-The two approaches map cleanly onto these audiences, and the right answer is
-likely **both** — but with a clear primary recommendation.
-
----
-
-## 3. Approach (a): Godot Editor Plugin
-
-### 3.1 What It Is
-
-A Godot editor plugin is a set of scripts (and optionally scenes) that extend
-the editor via the `EditorPlugin` API. It can add:
-
-- **Dock panels** (`add_control_to_dock`) — e.g., a chunk/tile palette panel.
-- **Toolbar buttons** (`add_control_to_container`).
-- **Inspector plugins** (`EditorInspectorPlugin`) — custom property editors.
-- **Import plugins** (`EditorImportPlugin`) — custom asset importers.
-- **Scene/Node plugins** (`EditorNode3DGizmoPlugin`) — custom gizmos.
-- **Menu entries** (`add_tool_menu_item`).
-
-Plugins are enabled per-project via `project.godot` (`[editor_plugins]`).
-
-### 3.2 Pros
-
-- **Full editor power for free:** You get the scene tree, inspector, viewport
-  navigation, undo/redo, gizmos, and asset pipeline — all battle-tested.
-- **Native Godot editing:** Editing `.tscn` scenes, materials, and nodes is
-  exactly what the editor is built for. Great for authoring **base content**
-  (rooms, templates, avatar base bodies).
-- **Fast iteration for devs:** The platform team can build and test levels
-  directly in the tool they already use.
-- **Undo/redo, selection, snapping** come from the editor's `EditorUndoRedoManager`.
-- **No runtime footprint:** Editor-only code is stripped from export builds
-  (`@tool` scripts and editor plugins are not shipped to players).
-
-### 3.3 Cons
-
-- **Not available to players.** Players don't run the Godot editor. Any
-  player-facing UGC authoring cannot use this approach.
-- **Tied to the editor's UX.** You inherit the editor's look and interaction
-  model; deep customization is limited by what the editor API exposes.
-- **Editor API churn.** `EditorPlugin` APIs change between Godot versions;
-  plugins are more brittle across upgrades than game code.
-- **Scene-centric, not data-centric.** The editor is optimized for scenes and
-  resources. Our world is **chunk data** (`world.md`). We'd have to build a
-  translation layer (scene ↔ chunk) and keep it in sync — a real source of
-  drift.
-- **Single-user, local.** The editor edits local files. It does not natively
-  talk to our server-authoritative chunk store or the moderation pipeline.
-- **Headless/CI friction.** Validating plugin behavior in CI requires running
-  the editor headless, which is heavier than testing game code.
-
-### 3.4 Fit for Our Constraints
-
-- **Platform/dev authoring:** Excellent. This is the natural home for building
-  base worlds, rooms, and templates.
-- **Player UGC:** Not applicable. Players cannot run the editor.
-- **Server-authoritative chunk store:** Poor fit natively. The editor edits
-  local scenes; we'd bolt on a chunk export/import and a server sync layer.
-
----
-
-## 4. Approach (b): In-Game Editor
-
-### 4.1 What It Is
-
-A fully custom editor built as **game UI** — Godot `Control` nodes (panels,
-buttons, toolbars) that run inside the running game. It edits the game's own
-world data model (chunks) and submits edits through the normal server pipeline.
-
-### 4.2 Pros
-
-- **Ships to players.** The editor is part of the game binary, so **player UGC
-  authoring is possible** — the core requirement for a user-generated-content
-  platform.
-- **Data-native.** The editor operates directly on the **chunk model**
-  (`world.md`), so there is no scene↔chunk translation layer and no drift.
-- **Server-authoritative by construction.** Edits go through the same
-  `request_chunk_edit` RPCs as gameplay, so validation, revisioning, and
-  moderation apply uniformly. The editor cannot bypass the server.
-- **Moderation-aware.** Because edits flow through the server, content flags are
-  computed and enforced at the boundary (`content_moderation.md` §4). The editor
-  can surface flags and gate mature content.
-- **One codebase, one UX.** The editor uses the same UI toolkit and art style as
-  the game; no separate editor theme to maintain.
-- **Testable in CI.** The editor is ordinary game code; it can be exercised
-  headlessly and unit-tested like any other system.
-
-### 4.3 Cons
-
-- **We build everything.** No free scene tree, inspector, gizmos, or undo/redo.
-  We must implement selection, snapping, undo/redo, viewport navigation, and
-  property editing ourselves.
-- **Runtime footprint.** Editor UI ships in the binary (though it can be gated
-  behind a feature flag / separate scene that is only instantiated on demand).
-- **More upfront work.** A usable in-game editor is a large feature; it needs
-  its own architecture (tool modes, gizmos, palette, inspector).
-- **Not ideal for deep asset authoring.** Modeling a mesh or authoring a
-  material is better done in the Godot editor / DCC tools. The in-game editor
-  should focus on **world composition** (placing tiles and objects), not asset
-  creation.
-
-### 4.4 Fit for Our Constraints
-
-- **Platform/dev authoring:** Workable but not ideal for deep asset work.
-- **Player UGC:** The **only** viable approach. Players can only author through
-  the shipped game.
-- **Server-authoritative chunk store:** Excellent fit. The editor is a client
-  that submits validated deltas.
-
----
-
-## 5. Comparison Matrix
-
-| Criterion | (a) Editor plugin | (b) In-game editor |
-|-----------|-------------------|--------------------|
-| Ships to players | ❌ No | ✅ Yes |
-| Player UGC authoring | ❌ Impossible | ✅ Core capability |
-| World data model fit | ⚠️ Scene-centric; needs translation layer | ✅ Chunk-native |
-| Server-authoritative edits | ⚠️ Bolted on | ✅ Native (same RPCs) |
-| Moderation enforcement | ⚠️ Manual | ✅ At the boundary |
-| Free editor features (undo, gizmos, inspector) | ✅ Rich | ❌ Build ourselves |
-| Runtime footprint | ✅ None (stripped from export) | ⚠️ Ships in binary (gated) |
-| Dev iteration speed | ✅ Fast | ⚠️ Slower to build |
-| Deep asset authoring (mesh/material) | ✅ Native | ❌ Out of scope |
-| CI testability | ⚠️ Heavier (headless editor) | ✅ Ordinary game code |
-| Editor API churn risk | ⚠️ Higher | ✅ None (game code) |
-
----
-
-## 6. Recommendation
-
-**Primary recommendation: build the in-game editor (b) as the platform's
-authoring surface, and use a lightweight Godot editor plugin (a) only as an
-internal dev convenience.**
-
-### 6.1 Rationale
-
-1. **Player UGC is the deciding factor.** The platform's value proposition is
-   user-generated content (rooms, worlds, avatars). Players cannot run the Godot
-   editor, so **only an in-game editor can deliver player authoring**. This is a
-   hard requirement that the editor-plugin approach cannot meet.
-
-2. **The world is data, and the in-game editor is data-native.** `world.md`
-   defines chunks as the atomic unit. An in-game editor edits chunks directly
-   and submits them through the server pipeline. An editor plugin would force a
-   scene↔chunk translation layer that is a constant source of drift and bugs.
-
-3. **Server authority and moderation fall out naturally.** Because in-game
-   edits use the same `request_chunk_edit` RPCs as gameplay, validation,
-   revisioning, optimistic concurrency, and content-flag enforcement
-   (`content_moderation.md`) apply uniformly. The editor cannot bypass the
-   server — which is exactly what a moderation-aware UGC platform needs.
-
-4. **The editor-plugin's strengths are not what we need.** Its free features
-   (scene tree, inspector, gizmos) are for editing Godot scenes and resources.
-   Our authoring is world composition against a chunk contract, not scene
-   editing. The plugin's main win — deep asset authoring — is better served by
-   DCC tools and the Godot editor for the *platform team*, not by a plugin we
-   must maintain.
-
-### 6.2 The Role of the Editor Plugin (Dev Convenience Only)
-
-We still recommend a **small, optional** editor plugin for the **platform team**
-to author **base content** (base rooms, templates, avatar base bodies, test
-levels) directly in the Godot editor. This is a dev-time convenience, not a
-product feature:
-
-- It can export a scene/resource as a **chunk** (reusing the same encoder as the
-  in-game editor) so dev-authored content flows into the same pipeline.
-- It is **not shipped** to players and is **not** the authoring surface for UGC.
-- It should be kept thin to minimize editor-API churn risk.
-
-### 6.3 Scope Boundary
-
-To keep the in-game editor tractable, define its scope clearly:
-
-- **In scope (world composition):** placing tiles, placing static/dynamic
-  objects, setting transforms, editing object properties, saving/loading chunks,
-  submitting edits to the server, showing moderation flags.
-- **Out of scope (asset creation):** modeling meshes, authoring materials,
-  rigging avatars. These are done in DCC tools / the Godot editor and imported
-  as catalog assets (see `avatar.md` §7). The in-game editor **references**
-  catalog assets by id; it does not create them.
-
----
-
-## 7. Resulting Architecture
-
-### 7.1 Shared Editor Core
-
-Both the in-game editor and the (optional) dev plugin should share a single
-**editor core** that operates on the chunk model. This avoids two divergent
-implementations.
-
-```
-EditorCore (shared, data-native)
-├── ChunkEditorModel      # in-memory chunk being edited (tiles, objects, flags)
-├── ChunkEncoder          # JSON/binary encode/decode (world.md §3)
-├── EditSession           # base_revision tracking, delta generation
-├── EditSubmitter         # request_chunk_edit RPC wrapper + conflict handling
-├── UndoRedoStack         # command pattern over chunk mutations
-├── SelectionManager      # selected tiles/objects
-├── ToolRegistry          # brush, object-place, select, erase, etc.
-└── ModerationView        # surfaces content flags; gates mature content
-```
-
-### 7.2 In-Game Editor (Primary)
-
-```
-InGameEditor (Control-based UI, shipped in binary, gated by feature flag)
-├── EditorViewport        # custom 2D/3D viewport with camera navigation
-├── Toolbar               # tool mode switcher
-├── PalettePanel          # tile/object palette (from catalog)
-├── InspectorPanel        # property editor for selected object
-├── ChunkBrowser          # load/save chunks, list rooms
-└── EditorCore            # shared core (above)
-```
-
-- Instantiated only when the player enters "build mode" (a separate scene /
-  feature flag), so the runtime footprint is negligible during normal play.
-- Submits edits via `request_chunk_edit`; handles `chunk_edit_result` conflicts
-  by re-fetching and re-applying (`world.md` §5.4).
-
-### 7.3 Dev Editor Plugin (Optional, Thin)
-
-```
-DevChunkPlugin (EditorPlugin, dev-only, not shipped)
-├── Dock panel: "Chunk Export"
-├── Reads the current scene / selected nodes
-├── Maps scene content → chunk model (via EditorCore.ChunkEncoder)
-└── Exports a .chunk.json / submits to a dev server
-```
-
-Kept thin to minimize editor-API churn. Its only job is to let the platform team
-author base content in the editor and push it into the same chunk pipeline.
-
-### 7.4 Data Flow
-
-```
-[In-game editor]  --request_chunk_edit(delta, base_revision)-->  [Server]
-        ^                                                          | validate
-        |                                                          | apply
-        +--chunk_edit_result(ok/new_revision | conflict)-----------| persist
-                                                                   v
-                                                              SQLite (world.db)
-
-[Dev plugin]  --export chunk JSON-->  [EditorCore.ChunkEncoder]  -->  [Server]
-```
-
-Both paths converge on the **same server validation pipeline**, so moderation
-and revisioning are uniform regardless of authoring surface.
-
----
-
-## 8. Risks & Mitigations
-
-| Risk | Mitigation |
-|------|------------|
-| In-game editor is a large build | Scope it to world composition (§6.3); reuse EditorCore; ship behind a feature flag |
-| Custom viewport/gizmos are hard | Start with a 2D tile editor (matches `CHUNK_SIZE_Z=1` default); add 3D later |
-| Undo/redo complexity | Use a command pattern over chunk mutations; test headlessly |
-| Editor-plugin API churn | Keep the plugin thin; treat it as dev-only convenience, not a product surface |
-| Drift between dev plugin and in-game editor | Both use the same `EditorCore`/`ChunkEncoder` |
-| Players bypass moderation | Impossible by construction: edits go through server validation |
-
----
-
-## 9. Open Questions / Future Work
-
-- **3D editing:** The default world is flat (`CHUNK_SIZE_Z=1`). A 3D in-game
-  editor (volumetric chunks) is future work (`world.md` §8).
-- **Collaborative editing:** Multiple players editing the same chunk concurrently
-  — the optimistic-concurrency model already supports it, but the UX (live
-  cursors, conflict resolution) is unspecified.
-- **Template library:** A curated set of room templates players can start from.
-- **Publish/review flow:** How a player's authored room enters the moderation
-  review queue (`content_moderation.md` §6) and becomes publicly joinable.
-
----
-
-## 10. Summary
-
-| Concern | Decision |
-|---------|----------|
-| Primary authoring surface | **In-game editor** (ships to players, enables UGC) |
-| Dev authoring convenience | Thin, optional **editor plugin** (not shipped) |
-| World data model | Both operate on the **chunk model** via a shared `EditorCore` |
-| Server authority | Edits go through `request_chunk_edit`; server validates |
-| Moderation | Enforced at the server boundary for both paths |
-| In-game editor scope | World composition only; asset creation is out of scope |
-| Runtime footprint | Editor gated behind a feature flag / separate scene |

docs/architecture/scripting_sandbox.md

@@ -0,0 +1,159 @@
+# GDScript Sandboxing for User-Written Scripts
+
+> **Status:** Proposed
+> **Owner:** Platform team
+> **Related:** Content moderation & age verification (scripts are one of the
+> three moderated content types), avatar component system
+
+## 1. Overview
+
+This document evaluates how to safely run **user-written scripts** as part of
+UGC (user-generated content) in **agp-game**, and recommends an approach.
+
+**Bottom line: Godot 4 has no built-in security sandbox for GDScript, and
+none of the three options named in the original task hold up under testing.**
+A script running anywhere inside the Godot process — however it's loaded,
+parented, or wrapped — runs with full engine privileges: arbitrary process
+execution, full filesystem read/write, and raw network access. Sandboxing
+has to happen *outside* the scripting language, not through an in-engine
+restriction mechanism, because no such mechanism exists.
+
+This was verified directly against Godot 4.6.2 (`godot --headless`, evidence
+in `sandbox_probe/` on this branch) rather than assumed from documentation,
+some of which (see §2.1) describes APIs that don't actually exist in this
+version.
+
+## 2. Options Evaluated
+
+### 2.1 Godot's built-in "ScriptServer" restrictions — does not exist
+
+There is no `ScriptServer` class in Godot 4.6.2:
+
+```
+ClassDB.class_exists("ScriptServer")  →  false
+```
+
+There's also no project setting to disable engine subsystems for scripts —
+none of `application/run/disable_os`, `disable_file_access`, or
+`disable_network` exist as settings, and `ProjectSettings.get_property_list()`
+returns nothing matching "sandbox", "restrict", or "security". Any plan that
+assumes a flag like this exists needs to be dropped; it was likely conflated
+with sandboxing features from a different engine/scripting ecosystem, or
+with **export template stripping** (which controls what ships in a build,
+not what a script can call at runtime).
+
+Directly probed capabilities of an ordinary GDScript running as a normal
+node script, no special setup:
+
+| Capability | Available to any script? |
+|---|---|
+| `OS.execute(...)` — run arbitrary processes | ✅ Yes |
+| `FileAccess.open(...)` — read/write any path the OS user can reach | ✅ Yes (read `/etc/hostname`, write `/tmp/...` both succeeded) |
+| `TCPServer` / `HTTPClient` / `HTTPRequest` / `PacketPeerUDP` / `WebSocketPeer` | ✅ All instantiate and work |
+| `ClassDB.instantiate(...)` — construct any engine class by name | ✅ Yes |
+| Loading and running a second script from source text at runtime (`GDScript.new()` + `.reload()`) | ✅ Yes |
+
+**Verdict: rejected.** There is nothing to configure here — the restriction
+surface this option assumed doesn't exist in the engine.
+
+### 2.2 Isolated SubViewport with a limited API — doesn't isolate scripts
+
+`SubViewport` is a **rendering and input isolation** primitive (it gives a
+scene subtree its own render target and can gate input propagation) — it is
+not a security or scripting boundary. A script attached to any node inside a
+`SubViewport` still runs in the same process, on the same GDScript VM, with
+the exact same access to `OS`, `FileAccess`, networking classes, and
+`ClassDB` as a script anywhere else in the tree. Nothing about being
+"inside" a SubViewport changes what API calls are reachable from a script.
+
+**Verdict: rejected.** This solves a rendering/UI-composition problem, not
+the security problem the task is asking about. Worth keeping in mind for
+other purposes (e.g. isolated preview rendering of user avatars), but it
+provides zero script sandboxing.
+
+### 2.3 Custom GDScript interpreter with an allowlist — right idea, wrong layer for "custom interpreter"
+
+Two ways to read this option, tested separately:
+
+**(a) Write/embed a separate GDScript parser+interpreter.** Not
+practical — this means re-implementing (and then indefinitely maintaining,
+in lockstep with every Godot release) a full language interpreter outside
+the engine. Far more engineering than the problem justifies.
+
+**(b) Use Godot's built-in `Expression` class as a restricted subset.**
+`Expression` *looks* like a natural allowlist mechanism — it only evaluates
+a single expression, no control flow, no arbitrary statements. But it isn't
+safe by default: it can still reach through to unsafe engine methods if you
+aren't careful about what object you hand it as a base instance:
+
+```gdscript
+var expr = Expression.new()
+expr.parse("get_environment('HOME')", ["OS"])
+expr.execute([], OS)   # → "/home/daddy"  (successfully called OS.get_environment)
+```
+
+So `Expression` is a viable building block only if the host **never passes
+a base instance (or arguments) that exposes anything sensitive** — i.e. the
+allowlisting work still has to happen at the call site, `Expression` itself
+enforces none of it.
+
+**Static text pattern-matching (blocklisting dangerous substrings like
+`"OS.execute"` before parsing) was also probed and is not a real
+defense** — it's trivially defeated by string concatenation, `call()`,
+`Callable`, or any other indirection, and produces false confidence.
+
+**Verdict: partially viable, but only as a foundation, not a solution on
+its own.** A hand-built, narrow, data-driven DSL (not full GDScript, not
+raw `Expression`) with an explicit allowlist of safe operations and *no
+ability to reference engine singletons or arbitrary objects* is the only
+version of "custom interpreter" that's actually safe. This is real
+engineering effort, not a config flag.
+
+## 3. Recommendation
+
+**Don't run untrusted GDScript in-process at all.** Given none of the three
+in-engine options provide a real boundary, the two approaches actually worth
+building are, in order of recommended priority:
+
+1. **Primary: a narrow, non-Turing-complete content DSL**, not general
+   scripting. Most UGC scripting needs in a game like this (custom
+   interactions, simple triggers, item behaviors) don't need a general
+   programming language — they need a small set of declarative
+   verbs/conditions (e.g. `on_interact: give_item("torch")`,
+   `on_enter: play_sound("chime")`). Expressed as data (JSON/Resource, not
+   code) and interpreted by trusted, hand-written GDScript on the engine
+   side. This has *zero* attack surface by construction — there's no
+   interpreter to escape because there's no general execution, just a
+   fixed, reviewed set of verbs. This is almost certainly sufficient for
+   the actual UGC use cases in this game and should be scoped against real
+   feature requirements before assuming more is needed.
+
+2. **If genuinely general scripting becomes a hard requirement**, isolate it
+   at the OS level, not the engine level: run untrusted scripts in a
+   **separate process** (a stripped-down Godot instance or a dedicated
+   interpreter) under OS sandboxing (a restricted user account, a
+   container, or `firejail`/`bwrap`/seccomp), communicating with the main
+   game over a narrow IPC/RPC boundary that only exposes intentionally-safe
+   operations. This is the only approach that provides a real security
+   boundary for arbitrary code, because it doesn't depend on the scripting
+   language cooperating — the OS enforces it. Substantially more
+   infrastructure than option 1; only worth it if option 1's DSL genuinely
+   can't express what's needed.
+
+**Do not** attempt in-process GDScript sandboxing via SubViewport,
+ScriptServer, or ad hoc blocklisting — all three were directly tested and
+none provide a real boundary (§2).
+
+## 4. Open Questions
+
+- What do actual planned UGC scripts need to *do*? (Trigger conditions,
+  simple item/state effects, dialogue branching?) This determines whether
+  the DSL in §3.1 is sufficient or whether §3.2's process isolation is
+  needed. Needs a concrete feature list before implementation starts.
+- If §3.2 is needed later, does it run per-user-session or shared/pooled?
+  Affects resource cost and isolation guarantees.
+- Interaction with the content moderation pipeline (`content_moderation.md`):
+  scripts as a moderated content type still need a moderation flag path
+  regardless of which execution model is chosen — a DSL makes static
+  analysis of *what a script can possibly do* far easier than it would be
+  for general code, which is an additional point in its favor.

project.godot

@@ -0,0 +1,24 @@
+; Engine configuration file.
+; It's best edited using the editor UI and not directly,
+; but it can also be edited by hand.
+
+config_version=5
+
+[application]
+
+config/name="AGP-Game"
+run/main_scene="res://scenes/main_menu.tscn"
+config/features=PackedStringArray("4.6.2")
+
+[autoload]
+
+[display]
+
+window/size/viewport_width=1920
+window/size/viewport_height=1080
+window/stretch/mode="canvas_items"
+
+[rendering]
+
+renderer/rendering_method="gl_compatibility"
+renderer/rendering_method.mobile="gl_compatibility"

sandbox_probe/.godot/.gdignore

@@ -0,0 +1 @@
+

sandbox_probe/probe6.gd

@@ -0,0 +1,174 @@
+extends Node
+
+func _ready():
+	print("=== SANDBOX PROBE 6: Corrected Evidence Gathering (Godot 4.6.2) ===")
+	probe_script_loading()
+	probe_os_apis()
+	probe_file_access()
+	probe_network()
+	probe_classdb()
+	probe_expression_engine()
+	probe_engine_singletons()
+	probe_worker_threads()
+	probe_project_settings()
+	probe_allowlist()
+	print("=== SANDBOX PROBE 6 END ===")
+	get_tree().quit()
+
+func probe_script_loading():
+	print("--- Script loading ---")
+	var gd = GDScript.new()
+	gd.source_code = "extends RefCounted\nfunc hello():\n\treturn 42\n"
+	var err = gd.reload()
+	print("GDScript.reload() from source_code err=", err)
+	if err == OK:
+		var inst = gd.new()
+		print("  instantiated, hello()=", inst.call("hello"))
+	var res = load("res://test_script.gd")
+	print("load('res://test_script.gd') = ", res)
+	if res:
+		print("  get_source_code() available: ", res.has_method("get_source_code"))
+	print("  GDScript instance has 'get_ast': ", gd.has_method("get_ast"))
+	print("  GDScript instance has 'get_parser': ", gd.has_method("get_parser"))
+	print("  GDScript instance has 'get_script_method_list': ", gd.has_method("get_script_method_list"))
+	print("  GDScript instance has 'get_script_property_list': ", gd.has_method("get_script_property_list"))
+
+func probe_os_apis():
+	print("--- OS APIs ---")
+	var out = []
+	var exit_code = OS.execute("echo", ["hello"], out)
+	print("OS.execute('echo') exit=", exit_code, " out=", out)
+	print("OS.get_environment('HOME') = ", OS.get_environment("HOME"))
+	print("OS has 'create_process': ", OS.has_method("create_process"))
+	print("OS.get_cmdline_args() = ", OS.get_cmdline_args())
+	print("OS.get_user_data_dir() = ", OS.get_user_data_dir())
+	print("OS.get_executable_path() = ", OS.get_executable_path())
+
+func probe_file_access():
+	print("--- File access ---")
+	var f = FileAccess.open("/etc/hostname", FileAccess.READ)
+	print("FileAccess.open('/etc/hostname') = ", f)
+	if f:
+		print("  content: ", f.get_as_text())
+		f.close()
+	var w = FileAccess.open("/tmp/godot_probe_write.txt", FileAccess.WRITE)
+	print("FileAccess.open('/tmp/...', WRITE) = ", w)
+	if w:
+		w.store_string("probe")
+		w.close()
+		print("  wrote to /tmp OK")
+	var dir = DirAccess.open("/")
+	print("DirAccess.open('/') = ", dir)
+	if dir:
+		var names = dir.get_files()
+		print("  root files count: ", names.size())
+	var res_dir = DirAccess.open("res://")
+	print("DirAccess.open('res://') = ", res_dir)
+	var user_dir = DirAccess.open("user://")
+	print("DirAccess.open('user://') = ", user_dir)
+
+func probe_network():
+	print("--- Network ---")
+	var tcp = TCPServer.new()
+	var bind_err = tcp.listen(0)
+	print("TCPServer.listen(0) err=", bind_err)
+	var http = HTTPClient.new()
+	print("HTTPClient instantiated: ", http != null)
+	var http_req = HTTPRequest.new()
+	print("HTTPRequest instantiated: ", http_req != null)
+	var udp = PacketPeerUDP.new()
+	print("PacketPeerUDP instantiated: ", udp != null)
+	var ws = WebSocketPeer.new()
+	print("WebSocketPeer instantiated: ", ws != null)
+
+func probe_classdb():
+	print("--- ClassDB ---")
+	print("ClassDB.class_exists('OS'): ", ClassDB.class_exists("OS"))
+	print("ClassDB.class_exists('FileAccess'): ", ClassDB.class_exists("FileAccess"))
+	print("ClassDB.class_exists('TCPServer'): ", ClassDB.class_exists("TCPServer"))
+	print("ClassDB.class_exists('HTTPClient'): ", ClassDB.class_exists("HTTPClient"))
+	var class_list = ClassDB.get_class_list()
+	print("ClassDB.get_class_list() count: ", class_list.size())
+	var os_methods = ClassDB.class_get_method_list("OS")
+	print("OS method count: ", os_methods.size())
+	var inst = ClassDB.instantiate("Node")
+	print("ClassDB.instantiate('Node') = ", inst)
+	print("ClassDB has 'class_get_singleton': ", ClassDB.has_method("class_get_singleton"))
+
+func probe_expression_engine():
+	print("--- Expression engine ---")
+	var expr = Expression.new()
+	var err = expr.parse("1 + 2")
+	print("Expression.parse('1 + 2') err=", err)
+	if err == OK:
+		var result = expr.execute()
+		print("  Expression.execute() = ", result)
+	var expr2 = Expression.new()
+	err = expr2.parse("OS.get_environment('HOME')")
+	print("Expression.parse('OS.get_environment') err=", err)
+	if err == OK:
+		var result2 = expr2.execute()
+		print("  Expression.execute() = ", result2)
+	var expr3 = Expression.new()
+	err = expr3.parse("get_environment('HOME')", ["OS"])
+	print("Expression.parse with base_instance err=", err)
+	if err == OK:
+		var result3 = expr3.execute([], OS)
+		print("  Expression.execute with OS base = ", result3)
+	var expr4 = Expression.new()
+	err = expr4.parse("FileAccess.open('/etc/hostname', 1)")
+	print("Expression.parse('FileAccess.open') err=", err)
+	if err == OK:
+		var result4 = expr4.execute()
+		print("  Expression.execute() = ", result4)
+	var expr5 = Expression.new()
+	err = expr5.parse("get_tree().quit()")
+	print("Expression.parse('get_tree().quit()') err=", err)
+	if err == OK:
+		var result5 = expr5.execute()
+		print("  Expression.execute() = ", result5)
+
+func probe_engine_singletons():
+	print("--- Engine singletons ---")
+	print("Engine has 'remove_singleton': ", Engine.has_method("remove_singleton"))
+	print("Engine has 'add_singleton': ", Engine.has_method("add_singleton"))
+	print("Engine.get_main_loop() = ", Engine.get_main_loop())
+
+func probe_worker_threads():
+	print("--- Worker threads ---")
+	var thread = Thread.new()
+	print("  Thread.new() = ", thread)
+	print("  WorkerThreadPool has 'add_task': ", WorkerThreadPool.has_method("add_task"))
+
+func probe_project_settings():
+	print("--- Project settings ---")
+	var settings = ProjectSettings.get_property_list()
+	var relevant = []
+	for s in settings:
+		var name = String(s.name)
+		if "sandbox" in name.to_lower() or "restrict" in name.to_lower() or "security" in name.to_lower():
+			relevant.append(name)
+	print("  Sandbox/security project settings: ", relevant)
+	print("  ProjectSettings has 'application/run/disable_os': ", ProjectSettings.has_setting("application/run/disable_os"))
+	print("  ProjectSettings has 'application/run/disable_file_access': ", ProjectSettings.has_setting("application/run/disable_file_access"))
+	print("  ProjectSettings has 'application/run/disable_network': ", ProjectSettings.has_setting("application/run/disable_network"))
+	print("  ProjectSettings has 'set_setting': ", ProjectSettings.has_method("set_setting"))
+	print("  ProjectSettings has 'save': ", ProjectSettings.has_method("save"))
+
+func probe_allowlist():
+	print("--- Allowlist / static analysis ---")
+	var dangerous_patterns = [
+		"OS.execute", "OS.create_process", "OS.get_environment",
+		"FileAccess.open", "DirAccess.open", "TCPServer", "HTTPClient",
+		"load(", "preload(", "ClassDB", "Engine.get_main_loop",
+		"get_tree().quit", "ProjectSettings"
+	]
+	var test_script = """extends Node
+func _ready():
+	var f = FileAccess.open("/etc/passwd", FileAccess.READ)
+	OS.execute("rm", ["-rf", "/"])
+"""
+	print("  Test script contains dangerous patterns:")
+	for p in dangerous_patterns:
+		if p in test_script:
+			print("    DETECTED: ", p)

sandbox_probe/probe6.tscn

@@ -0,0 +1,6 @@
+[gd_scene load_steps=2 format=3]
+
+[ext_resource type="Script" path="res://probe6.gd" id="1"]
+
+[node name="Probe6" type="Node"]
+script = ExtResource("1")

sandbox_probe/project.godot

@@ -0,0 +1,8 @@
+; Engine configuration file.
+config_version=5
+
+[application]
+
+config/name="sandbox_probe"
+run/main_scene="res://probe6.tscn"
+config/features=PackedStringArray("4.6")

sandbox_probe/test_script.gd

@@ -0,0 +1,4 @@
+extends RefCounted
+
+func hello():
+	return "from test_script.gd"