[DOCS] `/bg` and `←` detach docs omit `--allow-dangerously-skip-permissions` preservation for backgrounded sessions

Status Fixed / completed
Maintainer reply None cached
Activity 3 comments · opened May 16, 2026 · closed Jun 23, 2026

Documentation Type

Missing documentation (feature not documented)

Documentation Location

https://code.claude.com/docs/en/agent-view

Section/Topic

"Permission mode, model, and effort" in the agent view guide

Current Documentation

The docs currently say:

The permission mode depends on how you started the session. Backgrounding an existing session with /bg or ← keeps the current permission mode, so a session you switched to acceptEdits or auto stays in that mode after detaching. Dispatching from the agent view input or running claude --bg from your shell uses the defaultMode from that directory's settings, or the permissionMode from the dispatched subagent's frontmatter.

And the permission-modes page says:

bypassPermissions: appears after you start with --permission-mode bypassPermissions, --dangerously-skip-permissions, or --allow-dangerously-skip-permissions; the --allow- variant adds the mode to the cycle without activating it

What's Wrong or Missing?

The agent-view page explains that /bg and ← keep the current permission mode after detaching, but it does not document the narrower v2.1.143 behavior where detaching also preserves --allow-dangerously-skip-permissions.

That omission matters because --allow-dangerously-skip-permissions does not start the session in bypassPermissions; it only makes bypassPermissions available later in the Shift+Tab cycle. A reader who backgrounds a session with /bg or ← cannot tell from the current docs whether the forked background worker still has bypassPermissions available to cycle into, or whether that optional mode is lost during detach.

Suggested Improvement

Add a short note to agent-view near the detach/background permission-mode description clarifying that /bg and ← preserve --allow-dangerously-skip-permissions when they fork a background worker.

For example:

Before:

Backgrounding an existing session with /bg or ← keeps the current permission mode...

After:

Backgrounding an existing session with /bg or ← keeps the current permission mode. If the attached session was started with --allow-dangerously-skip-permissions, the forked background worker also keeps bypassPermissions available in its Shift+Tab cycle.

This could also cross-reference the permission-modes page so readers understand the difference between --dangerously-skip-permissions and --allow-dangerously-skip-permissions.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:
| Page | Line(s) | Context |
|------|---------|---------|
| https://code.claude.com/docs/en/agent-view | 308-314 | Detach/background behavior explains preserved permission mode but not preservation of --allow-dangerously-skip-permissions for the forked worker |
| https://code.claude.com/docs/en/permission-modes | 34-40 | Explains that --allow-dangerously-skip-permissions adds bypassPermissions to the Shift+Tab cycle, which is the behavior readers need when interpreting detached background workers |

Total scope: 2 pages affected

Version context: Changelog v2.1.143 says /bg and ← detach now preserve --allow-dangerously-skip-permissions, so the forked worker keeps bypass-permissions available in its Shift+Tab cycle.

View original on GitHub ↗

3 Comments

coygeek · 4 months ago

Verified against the latest docs; this still appears unresolved.

coygeek · 3 months ago

Issue #59595 Verification

Title: [DOCS] /bg and ← detach docs omit --allow-dangerously-skip-permissions preservation for backgrounded sessions
Issue Date: 2026-05-16
Verification Date: 2026-06-23
Status: RESOLVED

---

Issue Summary

This issue reports that the agent-view page documents that /bg and ← keep the current permission mode after detaching, but it does not document the v2.1.143 behavior where detaching also preserves --allow-dangerously-skip-permissions, so a reader cannot tell whether the forked background worker still has bypassPermissions available in its Shift+Tab cycle. The issue suggests adding a note clarifying that /bg and ← preserve --allow-dangerously-skip-permissions when they fork a background worker.

---

Verification Results

Claim 1: The agent-view page does not document that /bg and ← preserve --allow-dangerously-skip-permissions

Status: RESOLVED

At https://code.claude.com/docs/en/agent-view, lines 282-289, the "From inside a session" section lists the configuration flags that carry through to the backgrounded session, including:

--mcp-config and --strict-mcp-config --settings --add-dir --plugin-dir --fallback-model --allow-dangerously-skip-permissions

At the same page, line 293, the docs add an explicit note about the implication of carrying this flag through:

Carrying --allow-dangerously-skip-permissions through keeps bypassPermissions reachable in the backgrounded session, but it does not grant anything new. The mode still requires the same one-time interactive acceptance described in [Permission mode, model, and effort](#permission-mode-model-and-effort) before any session can use it.

At https://code.claude.com/docs/en/agent-view, line 412, the claude agents flag description also documents that --allow-dangerously-skip-permissions makes bypassPermissions available in each dispatched session's Shift+Tab cycle without starting in that mode.

Verdict: The current agent-view page explicitly documents that --allow-dangerously-skip-permissions is one of the configuration flags that carries through to the backgrounded session, and clarifies that this keeps bypassPermissions reachable in the backgrounded session — directly addressing the concern raised in the issue.

---

Claim 2: The permission-modes page lacks a clear cross-reference explaining the difference between --dangerously-skip-permissions and --allow-dangerously-skip-permissions

Status: RESOLVED

At https://code.claude.com/docs/en/permission-modes, line 37, the docs state:

bypassPermissions: appears after you start with --permission-mode bypassPermissions, --dangerously-skip-permissions, or --allow-dangerously-skip-permissions; the --allow- variant adds the mode to the cycle without activating it

At https://code.claude.com/docs/en/cli-reference, line 57, the CLI flag description reinforces this distinction:

--allow-dangerously-skip-permissions: Add bypassPermissions to the Shift+Tab mode cycle without starting in it. Lets you begin in a different mode like plan and switch to bypassPermissions later.

Verdict: Both pages distinguish --dangerously-skip-permissions (starts in bypass mode) from --allow-dangerously-skip-permissions (adds the mode to the cycle without activating it), and the agent-view page already cross-references both the permission-modes and cli-reference pages for these flags.

---

Current State

| Claim | Status |
|-------|--------|
| The agent-view page documents that /bg and ← preserve --allow-dangerously-skip-permissions | RESOLVED |
| The permission-modes page distinguishes --allow- from non---allow- variants | RESOLVED |

---

Suggested Fix

N/A - issue has been resolved.

---

References

  • URL: https://code.claude.com/docs/en/agent-view
  • Line 412: Description of claude agents accepting --allow-dangerously-skip-permissions to make bypassPermissions available in each dispatched session's Shift+Tab cycle.

---

Conclusion & Recommendation

Primary Concern: The agent-view page did not document that /bg and ← detach preserve --allow-dangerously-skip-permissions for the forked background worker.

Resolution Status: RESOLVED

Recommendation: CLOSE

The current agent-view documentation explicitly lists --allow-dangerously-skip-permissions among the configuration flags that carry through to the backgrounded session and clarifies that this keeps bypassPermissions reachable in the backgrounded session's Shift+Tab cycle.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.