sandbox.agent.memory is silently ignored: never extracted from frontmatter

[rbstp]

Analysis

sandbox.agent.memory is declared in the config struct, documented in the schema, and consumed by the AWF argument builder — but no code path ever assigns it. The value is dropped during frontmatter extraction, so memory: compiles with 0 errors and 0 warnings while --memory-limit never reaches the awf invocation.

Three of the four pieces are present:

1. Declared — pkg/workflow/sandbox.go:80: the Memory field, yaml tag memory,omitempty
2. Documented — pkg/parser/schemas/main_workflow_schema.json:3455: "Memory limit for the AWF container (e.g., '4g', '8g'). Passed as --memory-limit to AWF. If not specified, AWF's default memory limit is used."
3. Consumed — pkg/workflow/awf_helpers.go:792-794: appends --memory-limit when agentConfig.Memory != ""
4. Never assigned — extractAgentSandboxConfig (pkg/workflow/frontmatter_extraction_security.go:146) extracts id, type, version, platform, sudo, config, command, args, env, mounts, runtime, legacy-security, model-fallback and targets. memory is not among them.

grep -rn "\.Memory = " pkg/ returns no assignment to AgentSandboxConfig.Memory outside tests.

Reproduce

sandbox:
  agent:
    memory: 48g

gh aw compile reports success; the generated awf --config ... line in the lock file contains no --memory-limit.

Impact

Workflows silently fall back to AWF's default memory limit. Building a large .NET solution on a 64 GB runner, csc and MSBuild worker nodes are killed with exit 137, and nothing indicates the configured limit was discarded — the failure looks like an application problem rather than a dropped setting. sandbox.agent.args: ["--memory-limit", "48g"] is rejected by strict mode as an internal implementation detail, so there is no supported workaround.

Confirmed on v0.83.4, v0.84.1 and main (a4a8ff8).

Implementation Plan

1. Extract the field (pkg/workflow/frontmatter_extraction_security.go)

   In extractAgentSandboxConfig, add a memory block immediately before the // Extract runtime block at line 269, mirroring the mounts block at line 259:

   // Extract memory (memory limit for the AWF container)
   if memoryVal, hasMemory := agentObj["memory"]; hasMemory {
       if memoryStr, ok := memoryVal.(string); ok {
           agentConfig.Memory = memoryStr
           frontmatterExtractionSecurityLog.Printf("Extracted sandbox.agent.memory: %s", memoryStr)
       }
   }

2. Validate the format (pkg/workflow/sandbox_validation.go)

   Reuse validateBoundedQueryMemoryLimit (line 436), which already checks the 512m / 2g form, so memory: 48 or memory: 48gb fails at compile time rather than reaching Docker. Error message per the style guide, e.g. memory value "48gb" is not a valid limit. Expected a number followed by m or g. Example: memory: 8g.

3. Add extraction tests (pkg/workflow/frontmatter_extraction_security_test.go)

   • memory: 48g populates AgentSandboxConfig.Memory
   • omitted memory leaves it empty
   • a non-string value is ignored rather than panicking
   • an invalid format is rejected by validation

4. Add a compiled-output test

   Assert that a workflow declaring sandbox.agent.memory: 48g produces a lock file whose awf invocation contains --memory-limit 48g. Struct-level tests alone would not have caught this bug, since the struct field and its consumer were both already correct.

5. Document the field (docs/src/content/docs/reference/sandbox.md)

   memory currently appears only in the schema — the sandbox reference page does not mention it at all. Add it to the agent options with an example and a note that omitting it applies AWF's own default rather than no limit.