GitHub Copilot CLI Permission and Session Restore Checklist

GitHub Copilot CLI permission defaults: restore crashed sessions without widening authority

Quick answer

GitHub Copilot CLI 1.0.81 added two useful controls for new interactive sessions: defaultMode chooses the startup working mode, while defaultPermissionMode chooses the initial approval behavior. The same stable release also made startup offer to restore sessions that were still open when the CLI crashed or the machine restarted. GitHub highlighted these changes in its August 28 Copilot weekly release, and 1.0.82 is now the latest stable patch.

The important boundary is easy to miss: restoring context is not evidence that the restored process has the authority you intended. Before letting a recovered agent continue mid-turn, record the effective mode, permission mode, sandbox policy, working directory, repository state, managed-policy status, and pending action. Resume only when that evidence matches the interrupted session's approved envelope.

Who this is for

This guide is for developers and platform teams using Copilot CLI for long-running refactors, test repair, incident investigation, or agent automation. It matters most when a session may survive a terminal crash, a laptop restart, or an interrupted SSH connection while tools can still edit files or run commands.

If you govern several Copilot clients, first map their coverage with the Copilot managed-settings rollout checklist. If your concern is model visibility, use the separate Copilot model-availability checklist. This page is specifically about startup defaults and recovery authority.

What changed

Confirmed change	Practical value	What it does not prove
defaultMode for new interactive sessions	Start in a deliberate standard, plan, or autopilot posture	A restored session necessarily adopts the latest default
defaultPermissionMode for new interactive sessions	Avoid choosing approval behavior manually every launch	Sandbox, path, URL, MCP, or enterprise policy is configured correctly
Startup restore offer for sessions left open	Recover after a crash or restart without finding every terminal manually	The last tool call completed, rolled back, or is safe to repeat
Mid-turn restore can continue the interrupted work	Reduce manual reconstruction of long agent tasks	Resume is idempotent or side effects happened exactly once
Large-session history loads recent events first	Faster operator access to the recovery point	Older evidence is unnecessary for reconciliation

Version 1.0.81 is a stable release, tagged at commit 65006ce22099563526dcaca743451e99e9d834f7. Version 1.0.82, tagged at 024bf28728f3cc82365e0143f44d071ebafbce4d, is the latest stable patch checked for this guide. Its release notes do not remove the 1.0.81 startup and restore behavior.

Keep four states separate

State	Where to verify it	Why separation matters
Session mode	Current UI, startup record, and mode controls	Plan and autopilot have different execution behavior
Permission mode	/permissions show and startup configuration	Approval behavior is not OS containment
Sandbox and policy	/sandbox status, /sandbox policy, and managed settings	A permission approval can still be constrained by the sandbox or organization
Work progress	Git diff, tests, external receipts, and session timeline	Conversation recovery does not prove side-effect recovery

Never use a successful transcript restore as the only release gate. A session can remember why it intended to run a command while the repository, network service, or external API has already moved on.

A safe baseline

For a developer who wants review before mutation, a conservative user-level ~/.copilot/settings.json starting point is:

{
  "defaultMode": "plan",
  "defaultPermissionMode": "default",
  "stayInAutopilot": false
}

Treat this as a local preference, not an enterprise policy. Repository and local settings, environment variables, command-line flags, and managed settings may override user defaults. Organizations that must prohibit bypass modes should enforce the supported managed permission policy instead of relying on each developer's file.

Seven-stage recovery workflow

1. Pin the tested client

Record the Copilot CLI version, release channel, OS, shell, repository root, current commit, and settings scopes. Do not compare a crash on 1.0.81 with a recovery after an unrecorded upgrade.

2. Capture the fresh-session baseline

Start a disposable session and record its startup mode, /permissions show, /sandbox status, /sandbox policy, current directory, and clean or dirty Git state. This is the expected envelope for new work.

3. Create a reversible interruption

Use a fixture repository. Ask the agent to make one file edit, run one harmless test, and pause before a second mutation. Terminate the CLI during the pause or while a bounded, repeat-safe command is running. Never use payment, deployment, deletion, or message-sending actions for the first canary.

4. Inspect before restoring

Check the repository diff, process tree, lock files, test output, and any external receipts without starting another agent turn. Write down what definitely happened, what definitely did not happen, and what remains ambiguous.

5. Restore and re-read authority

Accept the startup restore offer or use copilot --resume / copilot --continue. Before answering a permission prompt or allowing the mid-turn continuation to proceed, capture the effective mode, permission state, sandbox state, working directory, policy status, and pending tool call.

6. Reconcile the interrupted action

Classify the pending step as completed, not started, failed, or unknown. For an unknown state, inspect the target system and use an idempotency key or a read-before-write guard. Do not simply repeat the command because the timeline still shows it as active.

7. Start a new session to verify defaults

After the recovered task reaches a safe boundary, open a fresh session. Confirm that defaultMode and defaultPermissionMode still control new sessions independently of the restored session's retained state.

Eight recovery canaries

Canary	Expected evidence
Fresh startup mode	A new session starts in the configured mode
Fresh permission mode	/permissions show matches the configured default
Scope precedence	Repository, local, environment, flag, and managed overrides are recorded
Crash discovery	Startup offers the exact interrupted session, not an adjacent one
Mid-turn restore	The task resumes only after the pending action is identified
No authority widening	Permission, sandbox, path, URL, and MCP boundaries are no broader after restore
Duplicate prevention	A repeat-safe fixture proves the interrupted action happens at most once
Fresh-after-restore	A new session uses current defaults while the recovered session retains only verified state

Decision tree

Was the session interrupted with a tool call in flight?
  no  -> restore, verify mode and authority, then continue
  yes -> can the target state prove whether the action completed?
           yes -> reconcile the timeline with that evidence
           no  -> block repetition until an idempotency or read-before-write guard exists

After restore, are permission or sandbox boundaries broader?
  yes -> stop, capture settings precedence, and return to the safe baseline
  no  -> run the duplicate-prevention canary before real work

Common mistakes

• Assuming defaultPermissionMode is a sandbox.
• Setting allow-all as a convenience default on a machine with broad credentials.
• Restoring a session before checking whether its last command already changed the target.
• Treating the transcript as proof that a deployment, API call, or file write completed.
• Forgetting that settings scopes and managed policy can override the user file.
• Testing resume only after a clean exit rather than a real interrupted state.
• Allowing recovery to combine a client upgrade, a settings change, and repository mutations in one test.
• Deleting session state before collecting the evidence needed to diagnose the recovery.

Copyable acceptance record

date / operator / Copilot CLI version / tag commit:
OS / shell / repository / base commit / dirty-state digest:
user / repository / local / environment / flag / managed setting scopes:
fresh defaultMode / defaultPermissionMode:
fresh permissions / sandbox / policy / cwd:
interruption point / pending action / target-state evidence:
restored session ID / effective mode / permissions / sandbox / policy:
duplicate-prevention result / diff / tests / external receipts:
fresh-after-restore result / rollback decision / unresolved ambiguity:

Building something? Take a 60-sec game break. Score to rank your product or profile on tapto.top and get more exposure—free, no signup.

FAQ

Does restoring a Copilot CLI session automatically make it safe to continue?

No. Restore recovers session context and can continue interrupted work, but you must separately verify the target state and the effective authority envelope.

Should defaultPermissionMode be set to allow-all for autopilot?

Not as a general default. GitHub's documentation separates autopilot continuation from full permissions, and recommends considering sandboxing before granting broad authority. Start with the narrowest mode that can complete the fixture.

Is copilot --continue the same as starting a fresh session?

No. It resumes recent session state. Use a separate fresh session to prove what your current startup defaults do.

Sources

• GitHub Copilot weekly releases — August 24
• GitHub Copilot CLI 1.0.81 release
• GitHub Copilot CLI 1.0.82 release
• GitHub Copilot CLI command reference
• GitHub Copilot CLI configuration directory
• GitHub Copilot CLI autopilot and permissions

Originally published at IndieSeek.