feat(explorer-agents): built-in `input_context` tool — for iterative context pack building
What variant of Codex are you using?
All (App, CLI, IDE Extension) — multi-explorer / agentic workflows
What feature would you like to see?
Problem
Explorer agents describe findings in free-form prose. The lead-agent has to
re-read source files itself and cannot trust accuracy. There is no mechanism
that forces an explorer to hand off actual code instead of paraphrasing it.
Proposed: built-in input_context tool
The context pack is a regular markdown file on disk at~/.codex/context_packs/{pack_name}_{session_id}/pack.md.input_context accepts a FREEFORM string in the same grammar as apply_patch,
with one additional hunk type: *** Anchor File: — which reads verbatim code
from a real file on disk and inserts it into the pack.
Reading and editing the pack uses existing tools — shell to read,apply_patch to edit structure/headings/rationale.
Examples
Creating the pack and anchoring code:
*** Begin Patch
+# Auth token refresh flow
+> TTL misconfigured in middleware — expiry check never fires
+
+## Token expiry check
+> Root cause — condition is inverted
+
*** Anchor File: src/auth/refresh.rs:42-67
*** Anchor File: src/auth/middleware.rs:101-118
+
+## Config defaults
+> Where the TTL constant is defined
+
*** Anchor File: config/defaults.toml
+
+## Diagram
+```mermaid
+graph TD
+ A --> B
+```
*** End PatchRe-anchoring after code changed:
*** Begin Patch
@@ ## Token expiry check
*** Anchor File: src/auth/refresh.rs:42-67
*** End Patch*** Anchor File:
*** Anchor File: <path>[:<start>-<end>]
- Reads the specified lines (or full file) from disk
- Inserts as a fenced code block labeled with path and line range
- Computes
CODE_REF=code:<path>#L<start>-L<end>@sha256:<hash>
Path traversal and invalid line ranges are rejected. All validation
is fail-closed.
What the lead-agent receives
The markdown file — verbatim anchored code with CODE_REF hashes,
section headings, rationale, optional mermaid diagrams. Lead-agent
builds patches directly from the pack.
Multiple explorers each build their own pack; lead-agent receives all
of them and can deduplicate by CODE_REF.
Why
- Explorer saves output tokens — instead of generating large diffs and code
blocks in its output, it places anchors and the actual content is pulled
from disk automatically
- Anchored code is read directly from disk — cannot be hallucinated
- Same patch grammar the agent already uses
- Context pack is a plain file — read/edit with existing tools
- One new hunk type, zero new commands to learn
Additional information
_No response_
5 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
@etraut-openai Hi Eric,
I've implemented and tested a standalone MCP tool that implements the concept described in this issue — structured context packing for agents.
Based on my testing, I can confidently confirm that the quality and accuracy of agent work improve significantly, and there is a meaningful reduction in output token costs by shifting toward cheaper input tokens. The
context_packapproach works as expected.This is not a promotion of my tool, but rather a proof-of-concept validating that the idea works in practice.
Reference implementation: https://github.com/AmirTlinov/context_pack
That's an interesting idea. I'm not sure that the MCP approach is the best but I'll have a look next week hopefully
I agree MCP is probably not the right long‑term integration point. I used it as a pragmatic
proof‑of‑concept because I needed this capability in my multi‑agent pipeline immediately, and it
let me validate the approach on real workloads before investing in a Codex‑native implementation.
In my tests it delivered what I was hoping for: it significantly improved handoff fidelity and reduced cost by shifting from verbose, subjective summaries to structured, concrete, verifiable facts.
For example, with fast/low‑cost explorer agents the orchestrator no longer has to go back to the repo and re‑validate everything after each report — the evidence is anchored and easy to trust.
And this isn’t limited to explorers. The same context‑pack handoff pattern generalizes across roles. A reviewer can receive a structured
apply_patchchange history (with headings/notes) plus an unmodified quote of the relevant user intent (or upstream agent intent) and the orchestrator’s review task. In my experience, reviews that used to take ~10 minutes can drop to 1–2 minutes, while quality improves and token cost becomes low enough that multiple review passes are practical.While testing this, I also noticed that the biggest cause of poor sub‑agent implementations isn’t only missing code context — it’s losing the user’s intent during handoffs. When sub‑agents receive only a dry TODO list plus context, they tend to execute mechanically. When they also receive the user’s intent verbatim (1:1), they behave much more proactively and stay aligned: the goal becomes fulfilling the user’s intent, not just checking off TODO items. The agents start acting like a cohesive team working toward a single outcome, rather than independent checklist executors.
As Codex continues moving toward multi‑agent workflows, this becomes increasingly important: the more agents you have in the chain, the higher the risk of “telephone game” drift unless intent and evidence are transferred with high fidelity.
If it would be helpful, I’d be happy to propose a Codex‑native, transport‑agnostic design and take a first implementation pass as a PR for review. If you have preferences on constraints (repo root binding, path validation/sandboxing, size limits, etc.), I can align with them.
This feature request hasn't received enough upvotes, so closing.