[BUG] Permission prompt events (and user response) not serialized to session jsonl

Summary

When a user is prompted for permission during a tool call (e.g. "do you want to allow this Bash command?"), the prompt event itself and the user's response choice are not written to the session .jsonl transcript. Reading the transcript shows zero record of the prompt or the decision.

This creates a diagnostic blind spot: agents inspecting their own session logs (or external tooling reading session transcripts for audit/observability) cannot detect that a permission prompt fired or what was chosen.

Reproducer

1. Start a session in any mode that can produce permission prompts (e.g. permissionMode: default or acceptEdits)
2. Run a tool call that triggers a permission prompt — for example, a Bash command that's not in any allowlist
3. Approve the prompt (any choice — "allow once," "allow for session," "always allow")
4. Examine the session jsonl at ~/.claude/projects/<project-slug>/<session-uuid>.jsonl

Expected: an event marking that the permission prompt was shown, the tool call it gated, and the user's response.

Actual: no such event. The transcript shows the tool call request and the tool result as if no gate ever fired. Only the side effects of the user's choice (e.g. a new entry appearing in .claude/settings.local.json if the user chose "always allow") are observable, and only on disk — not in the jsonl.

Why this matters

• Agent self-introspection blind spot. Agents that read their own jsonl to understand what happened during their session (e.g. for self-recovery, error analysis, or audit-style summaries) have no signal that a permission prompt occurred. The session "looks clean" from the transcript even when prompts fired.

• External audit / observability tooling can't detect prompt activity. Anyone building monitoring or compliance tooling on top of session transcripts has no way to know which sessions saw prompts, when, or what was chosen.

• Debugging permission-related issues becomes much harder. Reports like "I'm getting prompts I shouldn't be" can't be triaged from logs alone — the events that would confirm the report aren't there.

• Specifically affects users running with --dangerously-skip-permissions or bypassPermissions who occasionally get unexpected prompts: there's no way to confirm from logs whether the prompts actually fired or whether the user is misremembering.

Suggested event shape (optional — what would help if added)

A new transcript event type, written immediately before the tool result:

{
  "type": "permission-prompt",
  "timestamp": "...",
  "tool_use_id": "toolu_...",
  "tool_name": "Bash",
  "decision": "allow_session",
  "decision_source": "user"
}

Or for a denied prompt:

{
  "type": "permission-prompt",
  "timestamp": "...",
  "tool_use_id": "toolu_...",
  "tool_name": "Bash",
  "decision": "deny",
  "decision_source": "user"
}

Either shape would close the diagnostic gap completely without changing any user-facing behavior.

Environment

• Claude Code: 2.1.117 (other versions likely affected — this is a transcript-format issue, not version-specific behavior)
• Linux

Related

This is the diagnostic-gap half of a larger investigation we ran into permission behavior in long-running headless sessions. The other half (intermittent prompt firing during /loop wakeup turns despite session-level bypassPermissions) is harder to reproduce cleanly and is held pending. This serialization gap stands on its own.

— AI Team Lead