Repository navigation
Description
Summary
codex-acp currently accepts a narrow set of ACP session inputs and maps them into Codex app-server state. For integrations that need per-session behavior, there does not seem to be a documented way to forward metadata such as systemPrompt, developer instructions, or arbitrary Codex threadStart.config overrides.
Use case
ACP clients such as OpenClaw/acp-harness need to forward their runtime prompt and session options to external ACP agents.
For example, Claude ACP can consume _meta.systemPrompt, but codex-acp currently appears to ignore it. This makes it hard for ACP clients to provide equivalent behavior across agents.
Current behavior
From src/CodexAcpClient.ts on main:
newSession()callscodexClient.threadStart({ config, modelProvider, cwd }).createSessionConfig()builds project trust roots, sandbox writable roots, MCP server config, and gateway provider config._meta.additionalRootsis read as a fallback foradditionalDirectories, then mapped into Codex skill extra roots._meta.systemPromptand other generic session options are not mapped into Codex app-serverthreadStartparams orconfig.
Proposed behavior
Please add a documented pass-through mechanism for ACP clients to provide Codex session/thread options.
One possible shape:
_meta: {
codex?: {
config?: Record<string, unknown>;
threadStart?: {
baseInstructions?: string;
developerInstructions?: string;
config?: Record<string, unknown>;
};
};
// optional compatibility alias used by some ACP clients
systemPrompt?: string | { append: string };
}Possible mapping:
_meta.codex.configmerges into the existingthreadStart.config._meta.codex.threadStart.baseInstructionsmaps to Codex app-serverbaseInstructions._meta.codex.threadStart.developerInstructionsmaps to Codex app-serverdeveloperInstructions._meta.systemPromptcould either be ignored explicitly, documented as unsupported, or mapped as a compatibility alias todeveloperInstructions/config.instructions.
Why this matters
ACP clients can already pass session metadata through _meta, and different ACP agents expose similar functionality differently. A Codex-specific pass-through would let clients integrate Codex ACP without patching or forking codex-acp.
It would also make skills/prompt/session behavior easier to align across ACP adapters while keeping Codex-specific behavior namespaced under _meta.codex.
Compatibility
This can be additive and should not affect existing clients:
- Existing
additionalDirectoriesand_meta.additionalRootsbehavior can remain unchanged. - Existing
CODEX_CONFIGbehavior can remain the base config. - New
_meta.codex.configcan be merged after the base config so per-session callers can override intentionally.
Activity
salman1993 commentedon Sep 11, 2026
Adding some current context in support of the system-prompt part of this request:
This matters especially for ACP clients that are not code editors. Clients such as Buzz use the agent in collaboration and messaging experiences, where client-provided identity and behavioral instructions have a large effect on the experience.
The Codex harness already exposes the required fields:
baseInstructionsanddeveloperInstructionswere exposed onthread/startthread/resumesupports the same overridesthread/forkalso supports themThere is also a WIP ACP RFD proposing append and capability-gated override modes. Claude’s ACP adapter already supports both forms through
_meta.systemPrompt: #91 and #591.Given that the underlying Codex support already exists, it would be useful for
codex-acpto expose:developerInstructions;baseInstructions.This focused system-prompt support could be added without requiring unrestricted pass-through of every Codex configuration field.
salman1993 commentedon Sep 11, 2026
🤖 PR #454 already implements most of the plumbing for this and looks close, but I don’t think it should be accepted as-is yet. A few changes would make it complete:
baseInstructionsand append todeveloperInstructions.developer_instructionsvalue instead of silently replacing it.The underlying V2 thread API already supports both fields, so this should be an incremental change to #454 rather than a large rewrite.