Summary
For editor/update workflows, agents often edit large content in a local file, but must still emit the full final body inline in safe output payloads. This increases token cost and context pressure.
Request: add an opt-in safe_outputs capability to reference a local file for body content (for example body_file) while preserving the existing safety model.
Background / problem
Current pattern for large updates:
- Read issue/PR/discussion body
- Write to local file
- Edit surgically
- Emit safe output
Step 4 currently requires the entire body inline, even when the authoritative edited content is already on disk.
Proposed shape (example)
{
"type": "update_discussion",
"discussion_number": 123,
"body_file": "gh-aw-safe/body.md",
"body_sha256": "<digest>"
}
Apply to body-bearing operations where appropriate (e.g. update_discussion, update_issue, update_pull_request, add_comment, etc.).
Adversarial review / threat model
A naive implementation is unsafe. Main risks:
- policy bypass if file-based bodies skip current validators/sanitizers
- TOCTOU mismatch between reviewed content and posted content
- path exfiltration (pointing at unintended files)
- reduced auditability/provenance compared with inline payloads
- non-deterministic replay/staged behavior with mutable workspace state
- prompt-injection pivot to attacker-controlled file paths
- resource abuse via huge/binary files
Required guardrails
- Opt-in only (disabled by default)
- Strict path allowlist (for example under
$RUNNER_TEMP/gh-aw-safe/ only)
- Reject traversal/symlink escapes
- Text-only with hard size limits
body_sha256 required + verified
- Atomic single read/snapshot at safe-output execution
- Pass the exact same validation/sanitization pipeline used by inline bodies
- Emit audit metadata (path, digest, bytes) without leaking content by default
- Same deterministic behavior in staged/non-staged modes
Non-goals
- arbitrary file references across workspace
- bypassing existing safe-output content policy
- changing cross-run persistence semantics
Agentic implementation plan
-
Schema + parser updates
- Add optional
body_file / body_sha256 fields to relevant output item schemas.
- Enforce mutual exclusivity/precedence rules between
body and body_file.
-
Path resolution hardening
- Add a resolver that canonicalizes and enforces allowlisted root(s).
- Block traversal and symlink escapes.
-
Content ingestion layer
- Read file once, compute SHA-256, verify exact digest match.
- Enforce text-only and max-size checks before further processing.
-
Unify policy pipeline
- Route file-backed content into the existing body sanitizer/validator path (URL rules, mention/reference handling, footer/disclosure behavior, length constraints).
-
Execution + observability
- Ensure handlers use the frozen in-memory snapshot only.
- Emit structured audit fields for file source metadata.
-
Docs + examples
- Update safe-outputs docs with examples and explicit security constraints.
- Clarify recommended workflow pattern for surgical edits.
-
Tests
- Happy path: valid allowlisted file + digest.
- Failure cases: digest mismatch, binary file, oversize, disallowed path, symlink escape, both
body and body_file invalid combinations.
- Verify parity with inline-body sanitization behavior.
Acceptance criteria
Summary
For editor/update workflows, agents often edit large content in a local file, but must still emit the full final body inline in safe output payloads. This increases token cost and context pressure.
Request: add an opt-in safe_outputs capability to reference a local file for body content (for example
body_file) while preserving the existing safety model.Background / problem
Current pattern for large updates:
Step 4 currently requires the entire body inline, even when the authoritative edited content is already on disk.
Proposed shape (example)
{ "type": "update_discussion", "discussion_number": 123, "body_file": "gh-aw-safe/body.md", "body_sha256": "<digest>" }Apply to body-bearing operations where appropriate (e.g.
update_discussion,update_issue,update_pull_request,add_comment, etc.).Adversarial review / threat model
A naive implementation is unsafe. Main risks:
Required guardrails
$RUNNER_TEMP/gh-aw-safe/only)body_sha256required + verifiedNon-goals
Agentic implementation plan
Schema + parser updates
body_file/body_sha256fields to relevant output item schemas.bodyandbody_file.Path resolution hardening
Content ingestion layer
Unify policy pipeline
Execution + observability
Docs + examples
Tests
bodyandbody_fileinvalid combinations.Acceptance criteria
body_file