Skip to main content

Why These APIs Are Blocked

Summercraft’s submission policy is designed for creator code that may eventually run inside a shared production sandbox. The static scanner and human review enforce these boundaries today even though the automated production runtime sandbox is not live yet. To protect platform security and stability, submission blocks patterns that enable:
  • shell/process execution,
  • uncontrolled filesystem/network access,
  • runtime reflection/eval bypasses,
  • loading or embedding unsafe native/binary resources.

Important: Scanner Is Pattern-Based

If a blocked pattern appears in submitted source, upload fails, even when:
  • it is in an editor/debug branch,
  • it is inside dead code,
  • it is conditionally executed.

Full Blocked Pattern List

Reserved Paths (Blocked In .pck)

Packs are rejected if they include infrastructure paths, including:
  • res://sdk/
  • res://core/
  • res://server/
  • res://client/
  • res://official_games/
  • res://bootstrap.gd, res://bootstrap.tscn
  • res://project.godot
  • res://summer.cfg
  • res://export_presets.cfg
  • res://test_runner.gd, res://test_runner.tscn

Blocked Native/Binary Resource Extensions

Packs are also rejected if they include:
  • .gdextension
  • .so
  • .dll
  • .dylib
  • .framework
  • .res

Practical Guidance For AI-Generated Code

When generating code from prompts:
  1. Never generate “debug fallback” branches with blocked APIs.
  2. Prefer SDK primitives (Summer.data, Summer.economy, score/teams/sync helpers).
  3. Keep all file/network/process interactions out of creator game scripts.
  4. Use explicit method calls instead of reflective invocation helpers.
The alternatives in this table are contract guidance, not a deployment-status promise. Check platform capability status before promising hosting, matchmaking, transport, persistence, or economy behavior.