Fix double expansion in slash command arguments

[Copilot]

Slash command arguments were being expanded at the task level, then potentially re-expanded when substituted into command templates, violating single-expansion semantics.

Root cause: Task content was expanded before parsing, causing expansion patterns in slash command arguments to execute prematurely.

Changes:

• Parse task content before expansion - Separates text blocks from slash commands before any expansion occurs
• Expand text blocks only - Slash command arguments remain literal, preventing double expansion
• Command templates receive literals - Arguments are substituted as-is into command files, where they may reference parameters

Example:

# Task file
Text with expansion: ${user}
/deploy version="!`echo dangerous`"

# Before: Both expanded at task level (version executes command)
# After: Text expanded, version stays literal

Recommended pattern for dynamic command parameters:

# Pass parameters via CLI, reference in command files
coding-context -p VERSION=1.2.3 deploy

# Command file
Deploying version: ${VERSION}

Added integration tests verifying single-expansion behavior for both text blocks and slash command arguments.

Original prompt

We should only expand prompts once. Can you review the code and see if that is true?

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[alexec]

@copilot a simpler solution would be to expand commands, and then expand the resulting content.

[Copilot]

@copilot a simpler solution would be to expand commands, and then expand the resulting content.

Could you clarify what you mean by "expand commands, and then expand the resulting content"?

I see a few possible interpretations:

1. Substitute commands with their raw content, then expand everything once (but this wouldn't respect per-command expand_params settings)
2. Expand commands first, then expand task text (but this seems like the current approach)

The current fix parses before expanding to prevent slash command arguments from being expanded. Are you suggesting a different expansion order, or a code simplification?

[alexec]

@copilot sorry, just do a single expansion over the whole content post slash command expansion.

[Copilot]

@copilot sorry, just do a single expansion over the whole content post slash command expansion.

I've tried implementing a single expansion approach, but it conflicts with the expand_params: false setting for commands.

The current fix already ensures single expansion per file:

• Task text: expanded once
• Commands: expanded once (with slash command args as literals via the expand function's security feature)

A truly single expansion (one expand() call) would mean:

1. Assemble all content
2. Call expand once

But this can't respect expand_params: false for individual commands (test TestContext_Run_ExpandParams/command_with_expand_params:_false_preserves_parameters expects ${env} preserved).

Should we:

1. Keep the current approach (multiple expand calls, one per file)
2. Remove expand_params: false support for commands to enable single expansion
3. Different approach?

[Copilot]

Pull request overview

This PR fixes a double expansion vulnerability in slash command arguments where values could be expanded twice: once at the task level and again when substituted into command templates. The fix enforces single-expansion semantics by parsing task content before any expansion occurs, expanding only text blocks while keeping slash command arguments as literals for later substitution.

Key Changes

• Modified task processing to parse content before expansion, ensuring text and commands are handled separately
• Text blocks are expanded with parameters, while slash command arguments remain literal
• Command files receive literal argument values that are substituted (not re-expanded) into templates

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
pkg/codingcontext/context.go	Refactored task processing to parse before expansion, preventing double expansion of slash command arguments
integration_test.go	Added two integration tests verifying single-expansion behavior for parameters and command arguments

The implementation is correct and follows the established patterns in the codebase. The tests are comprehensive and properly verify the single-expansion guarantee. The rune-by-rune processing in the expand() function already provided the foundation for single-expansion, and this PR extends that guarantee to the task/command interaction layer.