Opt-in dynamic context placeholders for Codex skills

What variant of Codex are you using?

App, CLI.

What feature would you like to see?

would like Codex skills to support opt-in dynamic context placeholders: skill-authored shell commands that Codex can run at skill invocation time, replacing placeholders with bounded command output before the skill content is injected into model context.

For example, a PR summary skill could contain:

- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`

The skill would explicitly opt in through agents/openai.yaml:

dynamic_context:
  inline_command_placeholders: true
  allowed_commands:
    - "gh pr diff"
    - "gh pr view --comments"
    - "gh pr diff --name-only"
  timeout_seconds: 10
  max_output_chars: 20000
  max_placeholders: 8

Codex would then execute only the allowlisted commands and replace the placeholders with their output before using the skill.

Today, a similar workflow can be approximated with a UserPromptSubmit hook, but that behavior is turn-scoped and centralized outside the skill. A skill-level version would keep the live-context requirements, allowlist, and invocation behavior colocated with the skill itself.

Safety-wise, I think this should be opt-in and deny-by-default:

• no execution unless the skill explicitly enables dynamic placeholders
• exact allowlist matching for commands
• no execution during passive skill discovery, listing, previewing, or indexing
• execution only during an actual trusted skill invocation
• bounded command count, runtime, and output size
• no approval/sandbox bypass beyond Codex's active execution policy
• output should be visible/auditable and isolated from instructions, for example with fenced or structured output
• repo-local dynamic context should respect project trust

This would make skills more self-contained for workflows that need live local context, without turning SKILL.md into arbitrary shell execution.

Additional information

The main motivation is that the dynamic context policy belongs with the skill:

• the skill knows what live data it needs
• the skill can define which commands are safe for that context
• the skill can be distributed with its own context policy
• invocation remains explicit and auditable

Example use cases:

• Working-tree review skills can inject git diff and git status so the model reviews the actual local changes, not a stale or incomplete summary.
• PR summary/review skills can inject gh metadata, diffs, comments, and changed files so the skill starts from the same context a maintainer would inspect manually.
• Failure triage skills can inject the latest test output, CI logs, or application logs so diagnosis starts from the real failure rather than a user-pasted excerpt.
• Data/API workflow skills can inject a database schema snapshot, dbt metadata, or a live API response so the model does not rely on stale docs or guessed contracts.
• Project-local workflow skills can call approved repo scripts or internal CLIs so team-specific diagnostics stay packaged with the skill while still using fresh local state.

A possible implementation direction would be:

1. Parse optional dynamic_context metadata from agents/openai.yaml.
2. During skill invocation, scan the selected SKILL.md for !command`` placeholders.
3. Execute only exact allowlisted commands through Codex's existing execution path.
4. Replace placeholders with fenced/truncated command output or bounded failure diagnostics.
5. Continue with normal skill injection.

Details that likely need design input:

• whether this should apply only to explicit $skill invocation or also implicit invocation
• how stdout, stderr, non-zero exits, and timeouts should be represented
• which working directory and environment should be used
• whether repeated placeholders should rerun commands or reuse output within one invocation
• whether this should be Codex-specific metadata first or part of a broader skill standard

Claude Code documents a similar "inject dynamic context" pattern for skills. I think the same concept could fit Codex well because Codex already has skills, hooks, sandboxing, approvals, and shell/tool execution primitives.