RuneCLR first targets developer-owned C# hot updates and then managed UGC. The current trust model is trusted/controlled code only. The prototype does not isolate hostile scripts from the host process, user files, network, or other sessions. It must not be used to execute arbitrary public UGC with sensitive process privileges. See product direction.

Default quotas apply to host API calls and retained host resources. Voluntary checks do not limit arbitrary execution. An explicit native instruction-budget prototype on matching private runtimes adds terminal accounting for supported interpreted paths, with Windows and iOS simulator evidence; it does not interrupt every blocking framework/native call. Managed allocations are not hard-capped. Collectible contexts provide loading/unloading, not permissions. The native loader override blocks one path, not all native interop.

Recovery depends on the selected configuration. Native-budget experiments cover dead loops, catch/resume suppression and bounded cleanup, with separate finalizer-boundary controls. These do not guarantee recovery from arbitrary blocking calls, background threads, process failures or leaked references. Framework and host state can outlive a script. Manifest path checks validate packages, not filesystem isolation.

Development starts with controlled internal maps. Expanding the trust model requires runtime enforcement, a constrained framework surface, controlled package approval, abuse tests, and a threat-model review.

The package resolver checks declared paths, assembly identities and content hashes and prevents implicit private dependency fallback to arbitrary host assemblies. It trusts immutable package directories and the host framework inventory. Hashes do not authenticate approval; these legacy checks do not reject all native/R2R bodies. The new versioned managed-IL intake rejects embedded R2R/mixed/native implementations and initial unsupported interop routes without executing input assemblies. Structural validation is not complete IL semantic verification and does not defend against filesystem replacement races. The initial gameplay policy now checks actual entry and private IL at packaging and versioned load time against explicit type/member allowlists. It denies static reflection/loading, process/IO/network, background work and unsafe routes, including helpers and constructors. Recomputed hashes and producer metadata cannot authorize these APIs. This is a controlled-author restriction, not complete malicious-IL verification or runtime isolation. Legacy trusted fixture APIs remain outside the policy. Allowed computation can still allocate without a hard cap; unbudgeted code can loop indefinitely. Authenticated approval and isolation from runtime vulnerabilities are not implemented. Required interpretation is an explicit matching-private-runtime option, not the stock-SDK default.

The accepted execution strategy starts with interpreted UGC on all target platforms. Matching private builds now provide opt-in session-policy enforcement; full platform/feature coverage remains open. Interpretation does not itself provide a security boundary. Author-supplied R2R/native bodies must not execute through the initial restricted profile; trusted host/framework native code still needs explicit call/accounting limits. Future restricted UGC JIT requires equivalent enforcement rather than relying on compilation to confer safety. These UGC requirements do not make a complete hostile-code sandbox a prerequisite for trusted developer-owned hot updates.

Direct CLR object interaction avoids compulsory cross-language copying, not shared-process authority or reference-lifetime risks. A host retaining script objects, delegates, exceptions or metadata can prevent retirement. A future trusted-update SDK must document ownership and update approval/version rollback; the legacy fixture APIs are not that supported SDK.

The target intake model accepts author source/IL only as untrusted build inputs. Final runnable packages, including future R2R images, are generated by controlled server builds; author-supplied native bodies are never a direct execution route. Controlled compilation addresses artifact provenance, not malicious behavior, missing execution checks or vulnerabilities in the compiler/runtime. This build intake path now has a local operator-side prototype with fixed references, raw-source compilation and versioned content/provenance validation. It is not an authenticated server approval/distribution service. Compiler inputs need worker time/memory isolation before hostile public intake; legacy trusted APIs must not be exposed as author upload endpoints.

For accidental exposures or security-sensitive findings, use GitHub private vulnerability reporting if available. Otherwise contact the maintainer before posting sensitive details publicly. Ordinary prototype bugs can use issues.