Status line shows an opaque, undismissable "MR !<iid>" chip after creating a merge request; persists across restarts and leaks into other sessions

What happened

After Claude Code created a GitLab merge request in a session (via glab mr create), an MR !49 chip appeared in the status line footer, alongside the built-in auto mode on (shift+tab to cycle) and ⊢ 1 agent items.

The chip has no visible owner and no documented way to dismiss it. It also:

• survives a session restart, and
• appears in a second, unrelated session in a different working directory.

There is no affordance to identify what it represents or to clear it. /tasks shows nothing.

Why this is disruptive

It reads as "something is running." I spent a long stretch trying to determine what process was behind it and ruled out, one at a time:

• a custom statusLine command script (verified it emits only its own 2 lines, no MR logic)
• settings.json hooks (unrelated PostToolUse/Stop hooks only)
• every process started that day on the machine
• a project-local MR registration file written by a repo skill (reverted — no change)
• a long-running repo watcher script (killed — no change; this was a user process that did not need killing)
• ~/.claude.json, ~/.claude/daemon/roster.json, ~/.claude/jobs/pins.json, ~/.claude/jobs/*/state.json, ~/.claude/sessions/*.json

None of them is the source. Because the chip looks like a running-task indicator, the natural response is to go hunting for a process to stop — and there isn't one.

Expected

One of:

1. The chip is inspectable — hovering, /tasks, or a documented location says what it is and what created it; and
2. It is dismissible, and scoped to the session that created the MR rather than appearing in unrelated sessions; and
3. It clears on its own when the MR is merged or closed.

Actual

Opaque, persistent across restarts, leaks into other sessions, no documented way to clear it.

Environment

• Claude Code 2.1.259 (also observed on 2.1.258 — see below)
• Install method: native (~/.local/bin/claude → ~/.local/share/claude/versions/<version>)
• macOS (Darwin 25.5.0)
• Custom statusLine command configured

Not a 2.1.259 regression. The chip was visible at 15:28:51 local; the auto-update 2.1.258 → 2.1.259 (~/.claude/.last-update-result.json) ran at 15:39:41 local. So it was already present on 2.1.258.

Repro

1. In a git repo with a GitLab remote, have Claude Code run glab mr create.
2. Observe the MR !<iid> chip in the status line footer.
3. Restart the session — chip persists.
4. Open a session in a different directory — chip appears there too.

Side note

~/.claude.json has autoUpdates: false, but the native auto-update ran anyway (.last-update-result.json shows path: native, outcome: success). That may be intentional given autoUpdatesProtectedForNative: true, but the combination is surprising and worth documenting either way.