Feature: --fork-session should preserve session-level permission grants

Resolved 💬 2 comments Opened Feb 27, 2026 by mickdarling Closed Mar 27, 2026

Summary

--fork-session copies conversation history but does not preserve session-level permission grants ("Allow for this session"). The forked session starts with a clean permission slate for all ask-tier tools, requiring the user to re-approve everything interactively.

Since session-level grants are stored in-memory only (never serialized to the session JSONL), they are lost whenever a new process is created — including via --fork-session.

Use Case

When using MCP tools that require ask-level permission, each session requires an interactive approval ceremony. For workflows that need multiple MCP tool approvals (e.g., 4+ different tool calls), this is significant friction.

The intended workflow:

  1. Create a session interactively, approve all required tools → "golden" checkpoint
  2. claude --resume <golden-id> --fork-session → new working session with all permissions intact
  3. Use the fork for work
  4. If the working session dies, fork again from golden — no re-approval needed

This would eliminate the re-approval ceremony every time a session needs to be recreated (CLI updates, crashes, timeouts, etc.).

Current Behavior

# Phase 1: Create session, interactively approve an MCP tool in the "ask" tier
claude --session-id <id> --model sonnet 'call my_mcp_tool...'
# User clicks "Allow for this session" on the MCP tool

# Phase 2: Fork it headlessly
claude --resume <id> --fork-session -p 'call my_mcp_tool again...'
# RESULT: my_mcp_tool is BLOCKED — permission not carried over

Tested on Claude Code v2.1.62. The fork retains full conversation context and auto-allowed tools (from settings.json), but session-level grants for ask-tier tools are lost.

Expected Behavior

--fork-session should serialize session-level permission grants into the forked session, so the fork inherits the same tool approval state as the parent.

Proposed Implementation

Session-level permission grants could be serialized into the session JSONL file (e.g., as a permission-grants entry type). When --resume or --fork-session replays the session, it would reconstruct the permission state from these entries.

This would make permissions a natural part of session state — just like conversation history already is.

Reproduction Steps

  1. Configure an MCP tool in project .claude/settings.json under permissions.ask
  2. Start an interactive session: claude --session-id <uuid>
  3. Trigger the MCP tool call, approve with "Allow for this session"
  4. Verify the tool works without re-prompting within the same session
  5. Exit the session
  6. Fork it headlessly: claude --resume <uuid> --fork-session -p 'call the same MCP tool'
  7. Observe: the tool is blocked, permission grant was not preserved

Environment

  • Claude Code v2.1.62
  • macOS (Darwin 24.6.0, arm64)
  • MCP server with tools requiring ask-level permission

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗