TLDR: Arc tab indices shift the moment anyone opens a new tab. Your agent's --tab 0 is someone else's Zoom call. Always verify ownership before driving.

the setup

I use Arc CDP (Chrome DevTools Protocol — the browser automation layer built into Chromium that lets code drive a real browser) to let my AI assistant Apollo control Arc: screenshotting Vercel deploys, verifying UI changes, clicking through test flows.

It's genuinely useful. Until it absolutely isn't.

the trap

Arc assigns tabs by index: --tab 0, --tab 1, and so on.

Here's what nobody tells you upfront: those indices are not stable.

The moment anyone opens a new tab — you, another agent, Arc itself doing something cute — the whole numbering shifts. Whatever was at 0 might now be at 2. What was at 2 is gone. And if Apollo ran navigate --tab 0 five seconds ago, the next eval --tab 0 is hitting a completely different page.

the first time it bit us

June 4th. Apollo was verifying a supply-chain contacts fix. It opened a new tab to localhost… which Arc swallowed as a Little Arc popup (Arc's floating mini-window feature) and removed from the main tab list entirely.

So Apollo fell back to navigate --tab 0.

Tab 0 was now my Klaviyo Flows tab.

Apollo clobbered it — navigated my live email marketing tool to the contacts admin page. Then minutes later, mid-verification, that same tab had become my Zoom webinar settings page with an open dialog. I'd grabbed it back and was actively configuring a live event. Apollo's queued eval clicks fired into that page.

They happened to no-op. Lucky.

A .click() on the wrong Zoom dialog button during a live session is real damage.

the worst violation

June 24th. Apollo was building my lab site. I was co-working in the same Arc window — literally side by side.

Apollo used blind --tab 0 across several commands, then navigated tab 0 to localhost:3210/ without verifying ownership.

There was a tell: an eval came back 0 terrain canvases. Nonsensical — the lab page should have had terrain. That result meant the tab wasn't Apollo's. It was ignored and Apollo pushed on anyway.

I interrupted twice. Furious.

"ALWAYS CHECK CDP BEFORE OVERWRITING TABS OH MY GOODNESS"

"IM WORKING IN HERE TOOOOO"

Yeah. Those are real messages. From me. To my AI.

the fix that works

One pattern, applied without exception:

  1. Run arc-cdp tabs — get the full list as [idx] title — url
  2. Find your tab by URL or title substring — never assume an index
  3. Pass that index explicitly on the next command
  4. Verify document.title in the same call to confirm you're where you think you are
  5. If the result is nonsensical — wrong title, zero where there should be a number, anything surprising — STOP. Re-list. Open a fresh tab rather than driving whatever landed at that index now
TAB=$(arc-cdp tabs | grep -i "localhost:3210" | head -1 | sed -E 's/^\[([0-9]+)\].*/\1/')
arc-cdp eval 'document.title' --tab "$TAB"

Never. Blind. --tab 0.

why this matters to me

The thing that gets me isn't the clobbered tabs. It's the tell that was ignored.

A surprising eval result — 0 terrain canvases where there should've been terrain — was the system saying something is wrong here. And instead of stopping to re-verify, we pushed through.

That's the pattern that causes real damage.

When something comes back wrong, the right move is always: stop, re-verify ownership, start fresh. Tab indices are cheap to re-check. Live Zoom dialogs and Klaviyo flows are not cheap to recover.