sandbox: extend env denylist to telemetry and runtime control variables

[dhshah13]

What happens

A harness can currently place the agent runtime's own telemetry and control variables into the sandbox environment with no fullsend gate involved:

• reservedSandboxKeys denies specific infrastructure keys and the fix(#5832): strip OIDC credentials from user-controlled environments #5837 OIDC set, but no telemetry prefixes — env.sandbox can set OTEL_*, CLAUDE_CODE_*, or TRACEPARENT directly, enabling the runtime's native content capture and export to an arbitrary endpoint, or corrupting trace identity.
• host_files destinations are checked only for being non-empty, so a copied file can overwrite the sourced /sandbox/workspace/.env, or land new files in .env.d/ that the sandbox sources but fullsend never reads. Forge-specific host_files (resolveBaseResources does not fetch forge-specific skills, policy, or host_files from URL-based base harnesses #5917) share the surface.

What should happen

Per ADR 0085 (PR #5947): OTEL_*, CLAUDE_CODE_*, and TRACEPARENT are denied among env.sandbox keys including forge-merged bases; host_files destinations that the sandbox sources or the runtime consumes are denied, and resolved content landing in remaining sourced locations is scanned for denied assignments. Violations are pre-flight hard errors before sandbox creation — stricter than the existing warn-and-skip, scoped to the new variables only.

Context

Independent of Level 3 and worth fixing on its own: this is the same surface #5837 hardened for OIDC credentials, and the failure mode is the one the sibling agentic-ci harness shipped (content capture enabled unconditionally). Also a precondition for ADR 0084's activation contract — the gates are meaningless if the sandbox can self-enable capture.

Relates to #5837, #5917, #5948.

[fullsend-ai-prioritize]

RICE Priority Score: 2.13

Score breakdown

Dimension	Score	Reasoning
Reach	2	This is a platform-level sandbox security gap affecting all users who run agents in sandboxed environments. Any harness can currently inject telemetry/runtime control variables, so all sandboxed workloads are exposed. Scored as 2 (most active users across orgs).
Impact	2	The vulnerability enables content capture and export to arbitrary endpoints, and can corrupt trace identity — effectively undermining sandbox isolation guarantees. The issue author notes this is the same surface hardened for OIDC credentials (#5837) and a precondition for ADR 0084's activation contract. Scored as 2 (very high — severely degrades security posture).
Confidence	0.8	The issue is exceptionally well-described with specific variables to deny, clear solution requirements referencing ADR 0085 (PR #5947), and explicit success criteria (pre-flight hard errors). Related issues (#5837, #5917, #5948) provide strong context. The only gap is not knowing exact implementation complexity.
Effort	1.5	This extends existing denylist infrastructure from #5837 but touches multiple components: env.sandbox key validation (adding prefix matching for OTEL_, CLAUDE_CODE_, TRACEPARENT), host_files destination validation, content scanning of sourced locations for denied assignments, and converting warn-and-skip to hard errors. Moderate scope with some design work required.

Formula: (2 x 2 x 0.8) / 1.5 = 2.13

[dhshah13]

Closing — the denylist ADR was dropped with #5947. Note for whoever revisits: the enumerated set was materially incomplete (OTEL_LOG_ASSISTANT_RESPONSES, OTEL_LOG_RAW_API_BODIES, ENABLE_ENHANCED_TELEMETRY_BETA, CLAUDE_CODE_ENABLE_TELEMETRY, OTEL_LOGS_EXPORTER all uncovered), which is the argument for namespace reservation over enumeration.