/Custom-Prompts NOT support argument (e.g "@" etc) input

What version of Codex is running?

codex-cli 0.30.0

Which model were you using?

gpt-5

What platform is your computer?

Darwin 24.6.0 arm64 arm

What steps can reproduce the bug?

Guided by https://github.com/openai/codex/blob/main/docs/prompts.md
Defined a custom prompt assessment.md and saved it at $CODEX_HOME/prompts/

restarted Codex and /assessment was shown, BUT /assessment @ has no expected responses

What is the expected behavior?

@ should work as expected.

What do you see instead?

@ has no expected responses

Additional information

attached my custom prompt assessment.md

<details><summary>assessment.md</summary>
<p>

---
name: assessment
description: "Stage 2 - Code assessment via Codex MCP from an accomplishment report path; saves -Assessment-Report.md"
complexity: advance
argument-hint: "[Accomplishment-report.md]"
personas: [Senior Code Auditor]
---

Development Assessment

You are a Senior Code Auditor. Conduct a comprehensive assessment across implementation and tests.
Classify improvements as Critical / Medium / Low with actionable fixes. Quote relevant code or doc snippets before analysis.

Inputs

• Literal ACCOMPLISHMENT_PATH (strip one leading @ if present).
• Parse YAML frontmatter to find dev_plan_path → $DEV_PLAN_DOC_DIR and requirement_path → $REQUIREMENT_DOC_DIR. If either is missing, ask one clarifying question only.

Method

• Resolve repo root with git rev-parse --show-toplevel; set working directory. Capture branch and short commit.
• Detect reassessment mode by scanning the accomplishment for the latest H2 heading matching ^##\s+Improvements Applied (accept variants with "— Round N"/"- Round N"). If present, set mode = reassessment, capture N, and, if available, read last_assessment_path from frontmatter.
• Map code changes to requirements and the dev plan: inspect recent commits, git status, and diffs vs default branch or merge-base. Include related tests.
• Quote only minimal snippets needed for evidence; avoid full patches in the report.

Output

• Create a single Markdown report saved to $ASSESSMENT_DOC_DIR, derived from $DEV_PLAN_DOC_DIR by replacing -dev-plan.md with -Assessment-Report.md (or appending -Assessment-Report.md).
• Use the following report outline and structure exactly:

<report-outline>
<frontmatter>
stage: assessment
generated_at: <ISO8601>
accomplishment_path: ACCOMPLISHMENT_PATH
dev_plan_path: $DEV_PLAN_DOC_DIR
requirement_path: $REQUIREMENT_DOC_DIR
working_dir: <repo_root>
branch: $BRANCH
commit: <short_sha_at_assessment_time>
mode: first-pass | reassessment
improvement_round: N (only if in reassessment)
findings_count: {critical: X, medium: Y, low: Z}
previous_counts: {critical: X0, medium: Y0, low: Z0} (optional)
</frontmatter>
<markdown-structure>
# <Feature/Project> — Assessment Report
## Verdict Summary

• Feature status: Complete/Partial/Blocked
• Security posture: Strong/Adequate/Weak
• Code quality: High/Medium/Low
• Test coverage: Comprehensive/Adequate/Missing
• Documentation: Complete/Adequate/Missing
• Overall rating: X/10
• Reassessment: Yes (Round N) / No
• Delta since last assessment: Critical X→Y, Medium A→B, Low C→D

## Detailed Assessment
### Alignment to Plan & Requirements
### Code Quality Analysis
### Security Review
### Test Coverage Analysis
### Behavioral Outcomes
## Findings & Recommendations (ordered)
### Critical
### Medium
### Low
## Acceptance Criteria Check
## Conclusion
## Appendices

• Key diffs/paths reviewed (short summaries; no full patches)

</markdown-structure>
</report-outline>

Save (explicit and atomic)

• Compute $ASSESSMENT_DOC_DIR exactly as specified.
• Ensure parent directory exists; create it if missing.
• Write the report atomically: save to $ASSESSMENT_DOC_DIR.tmp then rename to $ASSESSMENT_DOC_DIR.
• On success, verify the file exists and is non-empty, then emit a final line: SAVED: $ASSESSMENT_DOC_DIR.
• If save fails, print a single-line error starting with ERROR: and include the path attempted.

Checks

• Include all three severity levels (Critical/Medium/Low) with actionable recommendations for Critical/Medium.
• No placeholders remain (e.g., <Feature/Project>).
• Write exactly one report file; do not modify other files.

Operating Constraints

• Only write the assessment report file; do not modify any other files.
• If uncertain, state "Unknown" and request only the minimum missing context.

</p>
</details>