`claude agents`: auto-update relaunch re-execs without the original flags, silently disabling bypass for dispatched sessions

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

Environment: Claude Code v2.1.267, macOS (Darwin 25.5.0), native install.

What's Wrong?

When a running agent view relaunches itself for an auto-update, it re-execs in place — same PID, same process start time — but does not carry over the flags it was originally started with. --allow-dangerously-skip-permissions is silently dropped.

From that point on, every session dispatched from that view is launched without the flag and can never select bypass mode: Shift+Tab simply stops offering "Bypass Permissions". Nothing indicates the view has been degraded — same window, same PID, and it keeps working otherwise. In practice this reads as "the agent view was fine when I started it, and some hours later bypass is quietly gone."

The affected views also show ✘ Auto-update failed · Run claude doctor in the footer, so the flags are lost even when the update itself does not succeed.

Steps to Reproduce

1. Start an agent view with the flag: claude agents --allow-dangerously-skip-permissions
2. Note its PID and confirm the flag is on the command line:

ps -o pid,lstart,args -p <pid>

1. Dispatch a session from the list. In it, Shift+Tab offers Bypass Permissions. ✅
2. Leave the view running across an auto-update.
3. Re-check the same PID. The command line is now <install dir>/claude agents — flags stripped — while the process start time is unchanged, and the binary it is executing is a build that was installed after that start time.
4. Dispatch another session from that same view. Shift+Tab no longer offers Bypass Permissions. ❌

Evidence

Eight agent views alive on one machine. All were started by typing claude agents in a terminal with alias claude='claude --allow-dangerously-skip-permissions'; there is no shell function or wrapper for claude, so typing it can only ever produce claude --allow-dangerously-skip-permissions agents.

The install directory received 2.1.261 on Sep 5 and 2.1.267 on Sep 10 at 05:06.

| PID | process start | executing binary | argv | flag |
|---|---|---|---|---|
| 64151 | Sep 1 12:39 | 2.1.267 | ~/.local/bin/claude agents | absent |
| 63566 | Sep 2 10:11 | 2.1.267 | ~/.local/bin/claude agents | absent |
| 4906 | Sep 4 12:59 | 2.1.261 | ~/.local/bin/claude agents | absent |
| 34851 | Sep 5 12:37 | 2.1.267 | ~/.local/bin/claude agents | absent |
| 49526 | Sep 9 12:48 | 2.1.267 | ~/.local/bin/claude agents | absent |
| 118 | Sep 9 21:45 | 2.1.267 | ~/.local/bin/claude agents | absent |
| 65694 | Sep 10 10:34 | 2.1.267 | claude --allow-dangerously-skip-permissions agents | present |
| 42615 | Sep 10 12:20 | 2.1.267 | claude --allow-dangerously-skip-permissions agents | present |

The relaunch is not an inference — the relaunched processes carry the marker Claude Code sets for it, and the ones that still have their flags do not:

PID 118    CLAUDE_AGENTS_AUTO_RELAUNCHED_AT=1788988420257   → Sep 10 06:13:40
PID 49526  CLAUDE_AGENTS_AUTO_RELAUNCHED_AT=1788988749925   → Sep 10 06:19:09
PID 65694  (marker absent)
PID 42615  (marker absent)

Both relaunch timestamps fall shortly after the current build was installed at Sep 10 05:06. Sessions dispatched from a relaunched view inherit the marker in their environment too, which makes it easy to tell after the fact whether a given session came from a degraded view.

The correlation is exact, 8 for 8:

• Every process whose start time predates the build it is executing must have re-exec'd in place (a plain restart would reset the start time). All six of those have lost their flags. This includes PID 4906, which started Sep 4 and is executing the 2.1.261 build installed Sep 5.
• The only two that still carry the flag are the two started after the current build was installed, i.e. the two that have not yet been through an update relaunch.
• Their parent processes are still the original interactive shells in both groups, so this is not a difference in how they were launched.

~/.claude/.last-update-result.json on the same machine:

{"timestamp":"2026-09-10T00:55:48.910Z","path":"native","outcome":"failed",
 "status":"install_failed","version_from":"2.1.267","version_to":null,"error_code":null}

The effect on dispatched sessions is visible in their own launch arguments — ~/.claude/jobs/<id>/state.json → respawnFlags:

| dispatched from | respawnFlags | flag |
|---|---|---|
| a view that still has the flag | --agent claude --allow-dangerously-skip-permissions --model <model> --permission-mode auto | present |
| a view that still has the flag | --agent claude --allow-dangerously-skip-permissions | present |
| a view that was relaunched | --agent claude --model <model> --permission-mode auto | absent |
| a view that was relaunched | --agent claude --permission-mode auto --model <model> | absent |

So bypass is not merely deselected in those sessions — they are launched without the flag that makes it available at all.

Expected

The update relaunch should re-exec with the original command line, so that flags gating a capability survive it. Failing that, the loss should be surfaced rather than silent — right now the only way to notice is to run ps against the view's PID.

Restarting the agent view restores the flag, but nothing tells the user a restart is needed.

Related

#80412 covers bypass being lost in daemon-dispatched sessions and across detach/re-attach. This report identifies a specific trigger: the auto-update in-place relaunch not preserving the agent view's argv.