Upstream Submission Package

Title

Add opt-in BeforeModelRequest context-transform hook with strict request-integrity guardrails

Issue Body (copy/paste)

Problem statement

Codex hooks can currently prune tool output and inject memory, but there is no supported point to safely transform the full model request immediately before send. This blocks Dynamic Context Pruning use cases that require ordered-item transformation with integrity checks instead of post-hoc compression only.

Proxy-based request rewriting can help in some local HTTP flows, but it is outside Codex core and depends on request shape compatibility. A first-class, guarded extension point is needed inside Codex itself.

Minimal API contract

Please consider an opt-in BeforeModelRequest hook that receives ordered request items and returns one of:

• continue with original items (no-op);
• transformed ordered items;
• structured refusal/diagnostics while fail-opening to original request.

Minimal conceptual shape:

trait ContextTransform {
    fn transform(&self, items: Vec<ResponseInputItem>) -> TransformResult;
}

An external command JSON contract is also acceptable if that aligns better with Codex hook architecture; the core requirement is deterministic validation of transformed item order and structure before send.

Safety constraints

The feature should be disabled by default and gated by:

• trusted workspace or explicit user opt-in;
• strict runtime timeout;
• max transformed payload size;
• schema validation;
• tool call/result pair integrity enforcement;
• user/system/developer message immutability by default;
• redacted audit diagnostics;
• fail-open behavior on timeout/crash/invalid transform.

Rejected transform payloads should include (at minimum):

• result without prior call;
• call without corresponding result where pairing is required;
• unauthorized changes to protected roles/instructions;
• schema-invalid items.

Acceptance questions for maintainers

1. Is BeforeModelRequest acceptable as an upstream extension point?
2. Should this be implemented as an external command hook, plugin API surface, or internal guarded hook first?
3. What minimum validation contract is required for transformed ordered input items?
4. Are there preferred defaults for runtime budget, redaction, and fail-open behavior?
5. What test evidence would be required for upstream consideration (synthetic fixtures, replay harness, compatibility matrix)?

Submission checklist

• Confirm preferred API surface (external hook vs plugin vs internal extension point).
• Confirm validation requirements for tool call/result integrity.
• Confirm policy for protected message roles/instruction immutability.
• Confirm acceptance criteria for initial PR scope (feature flag + tests + docs).
• Confirm maintainers' expectations for compatibility coverage across providers/auth modes.

Local submission-readiness evidence (2026-05-10)

• gh auth status failed: default account token is invalid for github.com.
• Repository remote is configured: origin https://github.com/hungcuong9125/codex-dcp.git.
• Next action: re-authenticate with gh auth login -h github.com, then open the issue using the body above.