Share Repo Context Across Coding Agents

To share context across coding agents, store stable repository knowledge in version-controlled files and let each tool load or reference that knowledge through its supported instruction system. Do not assume Claude Code, Codex, OpenCode, main agents, and subagents share one live context window, conversation, memory store, or permission state. They do not.

The practical pattern is a common repository contract plus thin tool-specific adapters. Share facts, constraints, and evidence. Keep credentials, permissions, model settings, private memory, and task history isolated.

Why Multi-Tool Agent Workflows Need Shared Context

A multi-model coding agent workflow often repeats the same discovery work. One agent finds the build command. Another reconstructs the package boundaries. A reviewer searches again for schema consumers. A subagent receives a vague task and misses the decision that made an unusual dependency intentional.

This repetition costs more than tokens. It creates conflicting interpretations of the repository. Two capable agents can read the same files yet choose different authorities when a README is stale, a test preserves legacy behavior, and the current implementation points elsewhere.

Shared repository context gives every workflow a governed starting point:

• supported build, lint, test, and generation commands;
• module ownership and architectural boundaries;
• public contracts, migrations, and compatibility rules;
• known test gaps and mandatory verification;
• links to current decision records and structural evidence.

The word shared needs a strict definition. It means the same versioned evidence is available to multiple tools. It does not mean that one tool can see another tool’s private transcript or that a subagent automatically inherits every conclusion from its parent.

That boundary matters when teams combine a Claude Code GPT workflow, Codex, and OpenCode. The model can change while the repository contract remains stable. The nearby Claudex context-engineering guide covers the narrower model-routing workflow; this page owns the cross-tool operating contract.

What Repository Context Should Be Shared

Share information that is stable enough to help future tasks and specific enough to verify. A useful common file is short, operational, and linked to deeper evidence rather than filled with a hand-written tour of every directory.

Context layer	Share across tools	Refresh trigger
Commands	supported setup, build, lint, test, and codegen commands	command or CI change
Architecture	package boundaries, allowed dependency directions, entry points	structural change
Contracts	APIs, events, schemas, migrations, compatibility windows	contract change
Governance	owners, approval thresholds, protected areas	ownership or policy change
Verification	required suites, known gaps, release checks	test strategy change
Evidence index	decision records, dependency maps, generated reports	source or index update

Use AGENTS.md as the neutral contract when the tool set includes Codex and OpenCode. Codex documents AGENTS.md as durable repository guidance. OpenCode includes project AGENTS.md in model context and can add more files through the instructions field in opencode.json.

Claude Code reads CLAUDE.md, not AGENTS.md. Its official documentation recommends a thin adapter that imports the shared file:

@AGENTS.md

# Claude Code only
- Use the project-specific reviewer agent for security-sensitive changes.

This avoids copying the same rules into two files that can drift. Claude Code supports imported files in CLAUDE.md, while OpenCode chooses AGENTS.md over CLAUDE.md when both exist for the project.

A repository knowledge graph can supplement this contract with current entity relationships: callers, imports, schemas, tests, owners, and decision documents. Treat the graph as an evidence index, not an authority that overrides source. Graphify follows this model by producing reusable repository artifacts that different coding assistants can query, while the agents still inspect code and run tests.

Do not share secrets, raw production data, personal preferences, transient stack traces, or an entire unfiltered transcript through the repository. Those belong in scoped tools, secure systems, or the current task handoff.

Coordinate Main Agents and Subagents

The main agent should own requirements, decisions, integration, and the final verification record. Subagents should receive bounded work that can return evidence without flooding the main thread.

Every delegation should state:

1. the goal and explicit non-goals;
2. files, modules, and contracts in scope;
3. relevant shared-context paths;
4. known callers, dependents, and risks;
5. whether edits are allowed;
6. acceptance tests and required evidence;
7. the expected return format.

Product behavior differs, so the handoff cannot rely on a universal inheritance rule.

Claude Code: a normal subagent starts with a fresh, isolated context and a delegation message, not the parent’s full conversation. Custom and most built-in subagents load the Claude memory hierarchy, but the built-in Explore and Plan agents skip CLAUDE.md and parent-session git status. Restate any critical exclusion or safety condition in their task. A Claude fork is different because it inherits the parent conversation.

Codex: subagents work in separate agent threads and return summaries to the main thread. Codex recommends parallelism first for read-heavy exploration, tests, triage, and summarization because parallel writers can create conflicts. Subagents inherit the active sandbox policy and the permission mode selected for the parent turn, while a custom agent can narrow its own sandbox.

OpenCode: primary agents can invoke subagents that run as navigable child sessions. Its General agent can perform broad work; Explore and Scout are read-only. OpenCode documents agent-specific permissions and permission.task rules for controlling delegation, but its public docs do not establish that every child receives the parent’s full history. Pass task evidence explicitly.

For write-heavy work, assign non-overlapping files or serialize implementation. Let parallel agents inspect callers, tests, and risks, then have one owner integrate the combined change. The Codex CLI guide’s limits and usage section provides additional context for choosing bounded runs instead of accumulating an oversized main thread.

Keep Tool-Specific Instructions Separate

The shared contract should describe the repository. Tool-specific files should describe how one product operates.

Keep these concerns separate:

• Claude agents, hooks, permissions, and local memory under Claude’s configuration;
• Codex custom agents, model choices, sandbox settings, and skills under Codex configuration;
• OpenCode agents, provider settings, permissions, and instruction globs under OpenCode configuration;
• local paths, credentials, tokens, and personal preferences outside committed shared files.

This separation prevents a repository fact from becoming coupled to one vendor’s syntax. “Package A must not import Package B” belongs in shared guidance. “Use the Explore subagent before editing” is tool-specific behavior. “Never change production data without approval” should appear as a shared policy and also be enforced through each tool’s permission layer.

Instructions are not enforcement. Claude explicitly treats CLAUDE.md as context rather than hard configuration. Codex and OpenCode also expose separate permission mechanisms. A sentence in AGENTS.md cannot grant file access, approve a shell command, or override a deny rule.

Keep the shared layer compact. Link to source-controlled architecture records, generated dependency reports, and test documentation instead of pasting them into every instruction file. Agents can retrieve the relevant detail for the current task.

Risks, Permissions and Update Rules

Shared context becomes dangerous when it is stale, over-broad, or treated as authorization. A confident obsolete map can steer every agent toward the same wrong conclusion.

Use the following controls:

• Named ownership: assign a team or maintainer to the shared contract.
• Change-coupled updates: update context in the pull request that changes the command, boundary, schema, or owner.
• Source provenance: link every generated map or graph edge to inspectable source.
• Freshness metadata: record the commit, generation time, and coverage limits for derived artifacts.
• Permission isolation: configure read, edit, shell, network, external-directory, and subagent permissions in each tool.
• Protected review: treat instruction and permission-file changes as security-sensitive configuration.
• Serialized integration: use one owner to reconcile parallel patches and run the final suite.
• Audit trail: retain task summaries, changed files, tests, approvals, and unresolved risks.

The tools have materially different defaults. Claude Code uses allow, ask, and deny rules with deny taking priority. Codex subagents inherit the active parent sandbox and permission mode. OpenCode allows most operations by default unless configured otherwise, while access outside the worktree and repeated identical calls default to asking. A shared policy should therefore state the desired control, and each tool should implement it explicitly.

Audit the final combined diff, not only each subagent’s local result. Cross-agent changes can pass isolated tests yet fail together through duplicated edits, incompatible assumptions, missed generated files, or a contract changed in two places.

FAQ

Who owns shared context in a multi-agent workflow?

Assign one accountable engineering group, usually platform, developer experience, or the owning service team. Code owners should review changes to their boundaries and commands. Derived graphs or reports also need an owner, refresh trigger, and documented coverage limit.

What should stay isolated per coding tool?

Keep model selection, agent definitions, permissions, hooks, provider settings, credentials, private memory, local preferences, and conversation history isolated. Share repository facts and verification rules, then adapt them through CLAUDE.md, AGENTS.md, or the tool’s supported instruction configuration.

How should teams audit cross-agent changes?

Record the base commit, task handoffs, agent roles, files changed, approvals, and test output. Review the merged diff for overlapping edits and missed dependents. Run focused tests first, then the repository’s required integration, build, type, security, or release checks.

Conclusion

The reliable way to share context across coding agents is to share governed repository knowledge, not live agent state. Use AGENTS.md as the neutral contract, a thin CLAUDE.md import for Claude Code, and native configuration for permissions and agent behavior.

Give every subagent a bounded evidence packet, keep one owner responsible for integration, and update the shared layer with the code. That lets models and tools change without forcing the team to rebuild repository understanding from zero—or accidentally share authority that should remain isolated.