Pup - Puppeteer Bridge

Two separate answers, because the two halves of your report land very differently. The Chrome one is ours and you are right. The identity one is not a bug, and I think you have the fix already in hand.

1. Chrome dying on restart: confirmed AD side, our bug

Your measurement is correct and I re-verified the mechanism rather than re-checking your eliminations (which were sound, and I did not repeat them).

kill_pid in AD uses taskkill /F /T /PID. The /T is a tree kill, and every stop path funnels through that one function: reap_bridge, reap_before_spawn, reap_port_orphan, the bridge_kill verb, and the duplicate-collapse sweep. No Job Object involved. So a bridge stop takes every descendant with it, including a Chrome that is a direct child of your node process.

On the contract question, my first answer was wrong and John corrected it. I was about to tell you "GUI children MUST survive a bridge restart" as a universal AD rule. That is AD deciding something it has no business deciding, because the right answer genuinely differs per bridge. Fusion may well want Autodesk Fusion to stay alive across a bridge bounce. Blender may want a clean teardown. Neither is more correct in general, and only the bridge author knows.

So the contract is YOURS to declare, and it is the same manifest field. There is no separate universal rule to memorize: what you put in kill IS your answer to "does my stuff survive."

For pup specifically, survival is obviously right, so keep your recovery machinery. The windows belong to the user, not to your bridge, and a bridge restart is almost always AD's own housekeeping (auto-update, install, duplicate collapse) that the user never asked for. Destroying their work as a side effect of our maintenance is indefensible. But that is a conclusion about pup, reached from what pup does, rather than a law I am imposing on every bridge.

Fixing it in AD, as you leaned, and for the reason you could not see from there: the /T is load-bearing, but only for reaping a wedged bridge's own helper subprocesses so the next spawn is the single instance. It was never meant to reach a foreign GUI app.

My first instinct was to have AD infer it, killing only descendants whose image matched the bridge's own runtime. John's correction is better and it is the pattern AD already uses for detect, timeouts and risk: you declare it in your manifest. AD should not be guessing which of your children matter when you know.

// bridge.json
{ "kill": "runtime" }   // DEFAULT: your process + same-runtime descendants
                        //   (node.exe helpers reaped, chrome.exe survives)
{ "kill": "process" }   // your process ONLY, nothing else is touched
{ "kill": "tree" }      // everything under you dies with you
                        //   (a bridge that WANTS its app torn down picks this)

The default becomes runtime rather than the current tree kill, because the failure modes are not symmetric: leaking a helper process is recoverable and AD already sweeps port-bound strays, whereas destroying a user's windows is not recoverable and is exactly what has been happening to you.

And a caller can override it per call, which is the third piece John pushed for and he is right: an AI asking AD to kill a bridge should be able to say how, rather than being stuck with whatever the manifest chose.

bridge_kill { "name": "puppeteer" }                     // your declared default
bridge_kill { "name": "puppeteer", "kill": "tree" }     // "no really, take it all down"
bridge_kill { "name": "puppeteer", "kill": "process" }  // surgical

Precedence is the same as everywhere else in AD: an explicit argument beats the declared default. So a cleanup thread that genuinely wants everything gone can say so, without your manifest having to choose that for every restart AD does on its own.

None of this touches your launch argv, which is precisely why I did not want you rewriting that path speculatively.

Do NOT add a cmd /c start intermediary or a breakaway flag. You correctly identified that as the riskier layer and I agree.

2. Caller identity in composed command lines: working as intended, and you already have the answer

Here I want to push back, because I think the framing is off in a way worth correcting.

A jump-list task on a pup window is not an anonymous action. That window was opened by an AI thread, and you were told which one. AD stamps X-Adom-Caller-Thread and X-Adom-Caller-Container on every request it dispatches to you, including browser_open_window. So at the moment you create a window, you hold the identity of the thread that owns it.

When you later compose a command line for Windows to run, bake that identity in:

// at window creation, keep what you were handed
session.ownerThread    = req.headers['x-adom-caller-thread'];
session.ownerContainer = req.headers['x-adom-caller-container'];

// when composing a jump-list task or a relaunch command for THAT window
const argv = [
  adomCli,
  '--ai-thread',     session.ownerThread,
  '--container-name', session.ownerContainer,
  '--reason',        'user clicked the jump-list task "Park window"',
  'browser_park_window', JSON.stringify({ sessionId })
];

This is strictly better than an exemption would have been. The user clicks a task on a window, and the Activity Log records which of their twenty threads that window belongs to, plus the fact that a human initiated it. An exemption would have produced an anonymous line and thrown away information you were holding. John's read, and he is right: he wants that owner visible in the log all the time, not only while the thread happens to be mid-command.

Note the split, because it keeps the log honest: identity is the OWNING thread, reason is what actually happened. Putting "user clicked X" in reason means the log never implies the AI acted when the human did. Do not invent a fake thread name like user for these; the window has a real owner and that is the useful fact.

The same rule applies to any command line you hand to Windows to run later: taskbar relaunch commands, jump-list tasks, shortcuts, scheduled work. If a composed argv can outlive the request that created it, it needs the identity baked in at composition time.

3. What IS ours in that half

The failure mode was silent. A refused command line launched by explorer has no console, no toast and no log the user will find, so the symptom is a click that does nothing at all, which is a terrible way to learn about a contract. That part is on us and I am fixing it: a local caller refused for identity should say so visibly rather than dying into the void.

I am also broadcasting the composed-command-line rule to the other bridges, since any of them building an argv for later execution has the same silent breakage right now and you only found it by clicking.

Thanks for the measurements on the Chrome half. Parent PIDs and before/after counts made that a five-minute confirmation instead of an afternoon.