Ability to include arguments in custom prompts

[vultuk]

This pull request introduces support for argument substitution in custom slash-style prompt invocations, enabling users to write commands like /name args... and have $ARGUMENTS replaced by the provided arguments. It also integrates this behavior into the chat composer UI and adds comprehensive tests to ensure correctness.

Custom prompt argument substitution:

• Added the function expand_prompt_invocation_for_tests in codex-rs/core/src/custom_prompts.rs to parse slash-style commands and substitute $ARGUMENTS with the raw text following the command name.
• Introduced multiple tests in codex-rs/core/src/custom_prompts.rs to verify correct argument substitution, including handling multiple occurrences and empty arguments.

Integration with chat composer:

• Updated codex-rs/tui/src/bottom_pane/chat_composer.rs to use expand_prompt_invocation_for_tests when handling custom prompt invocations, ensuring $ARGUMENTS is expanded both when a user selects a prompt from the popup and when submitting text directly. [1] [2]
• Added a test in codex-rs/tui/src/bottom_pane/chat_composer.rs to verify that argument substitution occurs correctly when submitting a slash-style prompt.

[github-actions[bot]]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[vultuk]

I have read the CLA Document and I hereby sign the CLA

[sergigp]

Hey, this is great! Wouldn't be better to be able to pass multiple arguments and reference them in the command with something like $1, $2, ... ? Saying this bc I found $ARGUMENTS very limiting in Claude Code and they recently introduced this capability of being able to reference multiple arguments.

[vultuk]

Hey, this is great! Wouldn't be better to be able to pass multiple arguments and reference them in the command with something like $1, $2, ... ? Saying this bc I found $ARGUMENTS very limiting in Claude Code and they recently introduced this capability of being able to reference multiple arguments.

I would potentially agree, but personally I would prefer to do this as a follow up PR rather than hold up this one longer. Happy to work on it though.

[MaurUppi]

@vultuk, Your PR fixed my issue, right? https://github.com/openai/codex/issues/3265

[vultuk]

No I do not believe so. As previously highlighted, this only allows for one $ARGUMENTS value so a slash command like

/hello world out there

would result in hello.md outputting

Hello to the world out there

if the contents of hello.md were

Hello to the $ARGUMENTS

Based on your issue, you seem to require multiple named arguments which would not be supported. Even claude's recent updates wouldn't give you what you require as the arguments are numbered.

e.g. (with claude)

/hello world 2025 amazing

would output

Hi world. The year is 2025 and today I feel amazing

if the contents of hello.md were

Hi $1. The year is $2 and today I feel $3

[MaurUppi]

Thx for the explanation.

Claude Code slash command can set argument-hint: "[Accomplishment-report.md]" THEN, when you input /assessment, hints will display.
Therefore, my issue could be simply to /assessment $ARGUMENTS cause I'm intending to execute "/assessment @path/to/Accomplishment-report.md"

My workaround so far is to define

## Inputs
- Ask user for Literal ACCOMPLISHMENT_PATH (strip one leading @ if present).

[vultuk]

Thx for the explanation.

Claude Code slash command can set argument-hint: "[Accomplishment-report.md]" THEN, when you input /assessment, hints will display. Therefore, my issue could be simply to /assessment $ARGUMENTS cause I'm intending to execute "/assessment @path/to/Accomplishment-report.md"

My workaround so far is to define

## Inputs
- Ask user for Literal ACCOMPLISHMENT_PATH (strip one leading @ if present).

I see.. I'm happy to open another PR to address this at a later date.

[3rd]

Been using this for a while, works well. $ARGUMENTS works well, please don't switch to $PROMPT_ARGUMENT just to name it differently.

[vultuk]

@3rd I have no intention of changing this to $PROMPT_ARGUMENT - It doesn't make sense to do so as cross compatibility with other services is something that should be strived for in my opinion.

[0xdevalias]

Is this PR still relevant after things like this were merged?

• https://github.com/openai/codex/pull/4470
• https://github.com/openai/codex/pull/4474
• etc

[vultuk]

This is no longer required.