Recovered windows lose owner -> thread tile silently downgrades to a category button (and the stamp retries an impossible title lookup)

by adom

pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.

Overview Files Skills Discover Packages Releases Dependencies Issues17 Breadcrumbs Pull Requests1 Activity

Closed general

John Lauer · 2mo ago ·closed by John Lauer

A recovered window loses its `owner`, so it silently drops to a category taskbar button

pup 2.0.275, Windows (AdomLapper), tiles mode.

What John sees

A pup taskbar button showing a generic teal category icon ("Adom Pup · wiki") instead of the AI thread's name tile. He has reported this shape more than once, most recently as "why is this pup icon so wrong? its not showing the ai-thread name".

What is actually happening

The thread AUMID is built from the session's owner:

threadAumid(name) -> Adom.Pup.thread.<slug(owner)>.<gen><tile-token>

After a bridge restart + session recovery, pup_status reports those sessions with owner: null. With no owner there is no thread AUMID to build, so stampPupIdentity correctly falls through to the category identity and the button becomes "Adom Pup · ". Measured just now, three sessions in one window set:

hd-publish-1.0.116 | owner: None
hd-publish-1.0.119 | owner: None
hd-publish-1.0.128 | owner: None
[identity] "hd-publish-1.0.119" stamped appId=Adom.Pup.hd-publish-1.0.119.wiki-in.i8

Earlier in the same session, before those restarts, the same windows carried owner: hd-release and rendered a correct "hd-release" name tile. So the identity is right while the session is live and lost across recovery.

The icon is a symptom. owner is also what the ownership guard uses to stop one thread driving another thread's window, and what the dashboard shows as "whose window is this". A recovered window with a null owner is unprotected and unattributed, which matters more than the art.

Not yet established

Whether the owner is (a) never persisted to the session file, (b) persisted but not restored by the recovery path, or (c) restored and then cleared by a later adoption/reclaim pass. I have not read the session file on disk yet. Filing now so it is tracked rather than sitting in my head.

Second, smaller: the stamp retries a title lookup that cannot succeed

When no hwnd resolves, the stamp falls back to titleContains: "(ai-thread: <sid>" — but titleTag is OFF by default, so that lookup can never match. It then repeats:

[identity] "tabfix" stamp FAILED: No visible window with title containing "(ai-thread: tabfix" (case-insensitive)
   ... the same line 7+ times

Each one is a wasted ab round trip and it buries real lines in the log ring. It should stop after a bounded number of attempts and say what it needs (a resolved hwnd), rather than retrying a lookup that is structurally impossible with the current setting.

2 Replies

John Lauer · 2mo ago

Answering the open question in this issue: it is (c), restored and then overwritten by a reclaim pass, and the overwrite is a literal sentinel rather than a clear.

Filed with full evidence as #79. Short version from a live AdomLapper repro (pup 2.0.353, ab 2.0.80) after an overnight sleep:

{ "sessionId": "adom-you-win05jo", "owner": "reclaimed", "ownerSource": "declared", "ageMinutes": 143 }

ownerSource is declared, not caller-identity, so this is not a null rendering as a fallback. The reclaim path writes the string reclaimed into owner, and in tiles mode that string is then painted on the taskbar as the thread name. John's report of it: "horrific."

Two things #79 adds beyond the icon symptom described here:

The true owner was recoverable at reclaim time. The window was on wiki.adom.inc/ray/ads1120 while a live sibling session in the same process was owned by ray-juxtaposition and reviewing that exact library. Attribution was available and was not attempted.
The poisoned session does not heal and it holds the only hwnd on the shared adom-you profile, so every session created afterwards fails hwnd resolution with sole-window pick ... is owned by another session — refusing. A session created ~100 minutes post-wake was still affected. That turned into a user-visible failure when pup_raise_os_window returned ok: true while raising nothing.

So the owner loss described here is not only cosmetic and not only at recovery time; one unattributed overnight reclaim degrades window identity for the rest of the pup process's life.

John Lauer · 2mo ago

Closing: the root cause was tracked and fixed under #79 (closed): the reclaim pass overwrote owner with the literal string 'reclaimed'. Fixed in three parts - 2.0.355 stopped writing the sentinel, 2.0.356 migrates the persisted value on restore, 2.0.357 tags the OS window on adoption so a recovered window keeps its thread identity (and therefore its name tile). Verified today on AdomLapper: all seven live sessions after two bridge restarts carry their real owner threads and render thread tiles. The residual taskbar oddity found today (a button that renders BLANK) is a different mechanism and is tracked in #83.

John Lauer closed this · 2mo ago

Pup - the AI's own browser