Misleading "user has taken control" error when navigation silently flips ownership to `agentDelegatedToUser`

Problem

openOrReuseTab / gotoAndWait flip a task space's ownership from agent to agentDelegatedToUser without any user interaction. The next helper call then fails with:

The user has taken control of this task space, so browser commands are paused.
This is a hard stop, not an obstacle to route around — do not retry and do not take control back on your own.

SKILL.md documents this as a hard stop that must not be routed around, so a well-behaved agent correctly stops and asks the user to confirm before resuming. But the user never touched the browser. The task stalls, the user replies "continue", and the cycle repeats on the next navigation.

In a single flight-search session this interrupted the task three separate times. The user's reaction was "I never took control" — they had been watching the agent run the whole time.

Root cause

The same error message is raised for two different ownership states:

• ownership: 'user' — a genuine user takeover, where stopping is correct.
• ownership: 'agentDelegatedToUser' — spurious, triggered by the agent's own navigation call.

From the error message alone an agent cannot tell them apart, so it must assume the stricter case and stop.

Reproduction

Observed 2026-08-24, macOS 25.5.0, ego lite via the ego-browser skill. Each numbered item is one heredoc round against the same task space:

1. openOrReuseTab(url) succeeds → the immediately following pageInfo() throws the takeover error.
2. useOrCreateTaskSpace(id) + gotoAndWait(url) → throws at gotoAndWait.
3. takeOverTaskSpace(id) + scrollBy() / js() only, no navigation → runs to completion with no error.
4. takeOverTaskSpace(id) + gotoAndWait(url) → throws at gotoAndWait again.
5. takeOverTaskSpace(id), then reclaim immediately after every navigation → runs to completion, two navigations, no error.

listTaskSpaces() captured at failure time reports agentDelegatedToUser, never user:

[{
  "createdBy": "agent",
  "id": 1,
  "name": "kyushu flight prices sep27",
  "ownership": "agentDelegatedToUser",
  "profileId": "Default"
}]

Rounds 3 and 5 isolate navigation as the trigger: the only round that succeeded without reclaiming was the one that performed no navigation.

Workaround

Wrapping navigation and reclaiming immediately afterwards makes it fully reliable:

async function nav(url) {
  try { await gotoAndWait(url, { timeout: 40, settle: 4 }) }
  catch (e) { cliLog('[nav flipped ownership, reclaiming]') }
  await takeOverTaskSpace(taskId)
  await wait(9)
}

This is unfortunate to have to recommend, since it means routinely calling takeOverTaskSpace — exactly the thing SKILL.md tells agents never to do on their own.

Suggested fix

Either would resolve it; (a) is preferable:

• (a) Don't delegate ownership on navigation initiated by the agent.
• (b) Use distinct error messages (or expose the ownership state in the error) so an agent can distinguish a real user takeover from a spurious delegation, and document the agentDelegatedToUser recovery path in SKILL.md.