[FEATURE] CLAUDE_CODE_OUTPUT_STYLE env var to override outputStyle for headless runs (claude -p)

Preflight Checklist

• [x] I have searched existing requests — the closest matches are #59155 (CLAUDE_CODE_OUTPUT_STYLE env var) and #6180 (output style in non-interactive mode), both auto-closed by the stale-bot for inactivity, not rejected on the merits. The bot's closing comment invited opening a new issue if still relevant.
• [x] This is a single feature request (not multiple features)

Problem Statement

outputStyle can only be set through settings files (user / project / local / managed) or interactively via /config. There is no environment variable to override it — unlike ANTHROPIC_MODEL, CLAUDE_CODE_EFFORT_LEVEL, CLAUDE_CODE_PERMISSION_MODE, etc.

This is painful for headless / automation usage. When a parent process (CI job, shell wrapper, agent harness) spawns claude -p sessions, each child silently inherits whatever outputStyle the user's interactive settings contain. A personal interactive style leaks into machine-facing runs and skews their output format, and there is no per-process way to force Default — or any named style — without mutating shared config files.

Use Case Example

I spawn automated code-review sessions via claude -p. My user settings set "outputStyle": "custom" for interactive work, and every review session inherits it, formatting machine-consumed reports in my personal style. I want:

# force the built-in Default style for one headless run
CLAUDE_CODE_OUTPUT_STYLE=Default claude -p "review this diff"

# or pin a named custom style for a scripted pipeline
CLAUDE_CODE_OUTPUT_STYLE=french-teacher claude -p "explain promises"

Proposed Solution

Add a CLAUDE_CODE_OUTPUT_STYLE env var, mirroring the precedence and semantics of CLAUDE_CODE_EFFORT_LEVEL:

• Takes precedence over all settings-file outputStyle values for that session
• Never persisted to any settings file
• Validates like the setting: unknown style name → warn and fall back to Default (or fail fast)

Alternative Solutions

• --settings '{"outputStyle":"..."}': works, but callers must generate a JSON file or inline blob, and the merge behavior of multiple --settings occurrences is undocumented — wrappers that already pass --settings (e.g. for credentials) cannot safely stack a second one. An env var composes cleanly through shell wrappers, CI matrices, and env(1).
• Editing settings files before launch: persistent, affects every other session on the machine, race-prone for parallel runs.
• CLAUDE_CODE_SAFE_MODE=1: does suppress output styles, but also disables CLAUDE.md, hooks, skills, MCP servers and more — far too broad for this need.
• --append-system-prompt / --system-prompt-file: pastes raw prompt text instead of resolving a named output style, and ignores style frontmatter semantics such as keep-coding-instructions.

Priority

Low - Nice to have

Feature Category

Configuration and settings

Additional Context

Prior art: #59155 (same env-var request), #6180 (output style for non-interactive mode). Both closed by automation for inactivity; happy to 👍 either one instead if a maintainer prefers reopening it.