[BUG] Argument order of -p and --append-system-prompt changes print-mode prompt behavior

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

In Claude Code print mode, changing the relative order of -p and --append-system-prompt changes whether the prompt supplied to -p is followed.

I encountered this while building a scripted repository-assessment workflow using Claude Code against an Anthropic-compatible local endpoint. The behavior initially appeared to be a model context or instruction-following problem, but a controlled A/B test isolated the CLI argument order as the variable.

With this ordering:

claude --bare --append-system-prompt $corePrompt
--allowedTools "Read" "Edit" "Bash" "PowerShell" -p $testPrompt
--verbose `
--output-format stream-json

the task prompt was effectively ignored. In a controlled test, $testPrompt requested a unique sentinel response. Instead of returning the sentinel, the agent began exploring the repository.

Changing only the argument order so that -p appears before --append-system-prompt:

claude --bare -p $testPrompt
--append-system-prompt $corePrompt --allowedTools "Read" "Edit" "Bash" "PowerShell"
--verbose `
--output-format stream-json

caused the same model, same system prompt, same task prompt, same tools, and same repository to behave correctly. It returned the requested sentinel immediately without making tool calls.

The same corrected ordering subsequently worked with the full repository-assessment task that had failed with the original ordering.

What Should Happen?

Named CLI options should have the same semantics regardless of their relative position.

These two invocations should deliver the same print prompt and appended system prompt:

claude --append-system-prompt "..." -p "..."

and:

claude -p "..." --append-system-prompt "..."

If argument order is intentionally significant, the CLI should document and preferably validate the required ordering rather than silently changing behavior.

Error Messages/Logs

Steps to Reproduce

A minimal test can use a unique sentinel so that prompt delivery is unambiguous.

PowerShell:

$corePrompt = @"
You are a coding agent.
Follow the user's immediate task precisely.
Do not inspect files unless the task requires it.
"@

$testPrompt = @"
Return exactly this text and nothing else:

PURPLE-ELEPHANT-47291

Do not use any tools.
"@
Test A — --append-system-prompt before -p
claude --bare --append-system-prompt $corePrompt
--allowedTools "Read" "Edit" "Bash" "PowerShell" -p $testPrompt
--verbose `
--output-format stream-json

Observed in my testing: the sentinel task was not followed and the agent instead began repository exploration/tool use.

Test B — -p before --append-system-prompt
claude --bare -p $testPrompt
--append-system-prompt $corePrompt --allowedTools "Read" "Edit" "Bash" "PowerShell"
--verbose `
--output-format stream-json

Observed: the agent returned:

PURPLE-ELEPHANT-47291

with no tool calls.

This was repeatable enough that I changed my automation to always place -p before the appended system prompt.

Environment
Claude Code: 2.1.274
Operating system: Windows 11
Shell: PowerShell
Mode: --bare
Output mode: --output-format stream-json --verbose
Model: qwen3-coder:30b
Endpoint: local Anthropic-compatible endpoint through Ollama
Model is reported by Claude Code as an unrecognized/custom model
Context window configured to 65,536 tokens
Additional Testing

Before isolating argument order, I tested several other possible causes:

Reduced the task to a unique sentinel response.
Tested the task prompt both from a PowerShell variable and as literal text.
Tested without the custom appended system prompt.
Verified that the model can perform structured Claude Code tool calls.
Verified that the comprehensive appended prompt works when -p precedes it.
Verified the corrected ordering on a real multi-turn repository-analysis task.
Confirmed that the problem was not caused simply by the size of the appended prompt.

The strongest A/B result was that keeping the model, prompts, tools, repository, and Claude Code configuration constant while changing only the relative position of -p and --append-system-prompt changed the behavior.

Caveat

I reproduced this using a local Anthropic-compatible endpoint and an unrecognized/custom model, not an Anthropic-hosted Claude model.

Therefore I cannot determine whether the underlying problem is in CLI argument parsing, print-mode prompt construction, the custom-endpoint compatibility path, or an interaction among those components.

However, argument ordering alone consistently changed the observable behavior, so it appears worth investigating at the Claude Code CLI/request-construction layer.

Workaround

Place -p before --append-system-prompt:

claude --bare -p $taskPrompt
--append-system-prompt $corePrompt `
...

For larger prompts on Windows, I am now also using stdin for the -p task and --append-system-prompt-file for the persistent system instructions:

$taskPrompt | claude --bare -p
--append-system-prompt-file ".\prompts\core-agent.md" --allowedTools "Read" "Edit" "Bash" "PowerShell"
--verbose `
--output-format stream-json

This both preserves the working argument ordering and avoids Windows command-line length limits.

Claude Model

Other

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.274

Platform

Other

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response

No repository files or tests are named. Start by reproducing the two print-mode invocations with -p and --append-system-prompt in each order, then trace the CLI argument parsing and print-mode request construction; done means both orders deliver equivalent prompts, with regression coverage for the observed behavior.