Claude Code System Prompt Assembly and Structure Revealed

System Prompt Assembly Flow

The system prompt is assembled in a fixed order in src/constants/prompts.ts via getSystemPrompt(). The structure follows: static content first, then a dynamic boundary marker, then session/user-specific suffix.

return [
  // Static content (cacheable)
  getSimpleIntroSection(),
  getSimpleSystemSection(),
  getSimpleDoingTasksSection(),
  getActionsSection(),
  getUsingYourToolsSection(),
  getSimpleToneAndStyleSection(),
  getOutputEfficiencySection(),
  // Cache boundary
  SYSTEM_PROMPT_DYNAMIC_BOUNDARY,
  // Dynamic/session content
  getSessionSpecificGuidanceSection(),
  loadMemoryPrompt(),
  getAntModelOverrideSection(),
  computeSimpleEnvInfo(),
  getLanguageSection(),
  getOutputStyleSection(),
  getMcpInstructionsSection(),
  getScratchpadInstructions(),
  getFunctionResultClearingSection(),
  SUMMARIZE_TOOL_RESULTS_SECTION,
]

Identity Prefix Variants

Three identity variants are defined in src/constants/system.ts:

• Default interactive mode: "You are Claude Code, Anthropic's official CLI for Claude."
• Agent SDK preset (non-interactive + append system prompt): "You are Claude Code, Anthropic's official CLI for Claude, running within the Claude Agent SDK."
• Agent SDK no-append (non-interactive): "You are a Claude agent, built on Anthropic's Claude Agent SDK."

The selection path is simplified as: Vertex API → default | non-interactive + append → SDK preset | non-interactive → SDK | else → default.

Attribution/Billing Header

Observed format: x-anthropic-billing-header: cc_version={version}.{fingerprint}; cc_entrypoint={entrypoint}; [cch=00000;] [cc_workload={type};]

Notes: cch=00000 appears to be a client-auth placeholder rewritten later by the HTTP stack. cc_workload={type} seems to act as a routing/scheduling hint (e.g. cron-like workloads).

Prompt Section Details

The intro section from getSimpleIntroSection() states: "You are an interactive agent that helps users with software engineering tasks. Use the instructions below and the tools available to you to assist the user."

The system rules section (getSimpleSystemSection()) includes high-level emphasis on: only assisting with authorized/defensive security contexts; refusing destructive/malicious usage patterns; not hallucinating URLs (unless clearly safe/programming-related); treating system reminders and hook feedback as structured control signals; watching for prompt injection in tool outputs; and automatic context compression as history grows.

Task execution guidelines (getSimpleDoingTasksSection()) contain core directives: do actual engineering work in files, not just give abstract answers; read code before modifying; avoid unnecessary new files; avoid speculative refactors or over-engineering; prioritize secure code; diagnose failures before switching approach; and verify outcomes honestly (don't claim checks passed when they didn't). There's also an additional instruction set for internal users reinforcing: collaborator mindset, minimal comments, and truthful verification reporting.

Safe execution guidelines (getActionsSection()) frame actions by reversibility + blast radius. Guidance pattern: local/reversible actions: usually proceed; destructive, shared-state, or hard-to-reverse actions: confirm first; prior one-time approval does not imply blanket future approval; investigate unexpected state before deleting/overwriting; don't bypass safeguards (e.g. avoid --no-verify shortcuts). Examples requiring confirmation include force-pushes.