Dynamic Expressions, Command Substitution, and Context Variables in Custom Prompts
I’d like to see support for dynamic content in Codex Custom Prompts, allowing them to include real-time data, shell command output, and contextual variables at runtime.
Currently, Codex Custom Prompts work as static Markdown files that support simple argument substitution ($1..$9, $ARGUMENTS). This is powerful for reusable templates but limited when prompts need dynamic or contextual data — such as current time, Git branch, project name, system status and many more.
---
Proposal
Introduce a system for evaluating dynamic expressions or substituting shell command output directly within a prompt file before submission.
Possible syntaxes:
- Command substitution (shell-like)
``markdown$(git rev-parse --abbrev-ref HEAD)`
Current branch:
- Expression blocks
``markdown``
Today’s date: {{ now() }}
Open files: {{ exec('ls -1 | wc -l') }}
- Environment variable expansion
``markdown``
Project: $PROJECT_NAME
User: $USER
The idea is that when a custom prompt is invoked, Codex evaluates these expressions dynamically and replaces them with their current values before sending the message.
---
Example Use Cases
- Code review automation
``markdown$(git rev-parse --abbrev-ref HEAD)
Review code changes for branch:
- Documentation generation
``markdown``
Generate release notes for version {{ exec('cat VERSION') }}
Date: {{ now(format='%Y-%m-%d') }}
- System or context-aware prompts
``markdown``
Summarize logs from directory: $(pwd)
Additional information
_No response_
5 Comments
We've added support for prompts with parameters, which is effectively the same as what is being described here.
@etraut-openai That's explicitly NOT what is being asked for here.
The original issue description makes it clear that it isn't talking about custom prompts with parameters, which the original poster was already aware of:
It is asking for something quite different:
Please re-open this, as it was closed incorrectly. Or at the very least, if you are still going to keep it closed, at least provide reasoning that shows you have evaluated and decided against what is being proposed explicitly; as currently your reasoning just sounds like you rushed to close it without actually reading/understanding the proposal.
OK, reopening
@etraut-openai Thankyou :)
This feature request hasn't received enough upvotes, so I'm going to close it. I think there may be something of value in this idea, but it's presented in a way that I think is difficult to understand. If you'd like to take another swing at opening a feature request and pitching it in a different way, you might be able to garner additional interest from the community.