Resetting a Bot's computer deletes its container profile and signs it out of everything, but the activity pane beside the chat goes on listing every command that ran on it. The pane presents commands and file operations from a wiped machine as though they were still true of the computer in front of you, and only a full page reload clears them.
What it looks like
After Reset succeeds — POST /api/computers/general-assistant/computers/reset returns 200, and a computer.reset row lands in the audit trail — navigating back to the channel still shows:
Activity
Ran
echo repro-marker-bravo
02:16:45
repro-marker-bravo
That command ran on the profile the reset deleted. Nothing distinguishes it from a command that ran on the profile that exists now.
Why it happens
The activity store is a module-level map in the browser keyed by Bot id — byComputer in app/src/lib/computers/activity.ts:46, read by ActivityLog and mounted as <ActivityLog computerId={agentId} /> in app/src/routes/_authed/_app/channel/$channelId.tsx:72. A reset replaces the container and the profile; it does not change the Bot id, so the map entry survives it.
The function that would fix this exists and already carries this exact reasoning. clearActivity at app/src/lib/computers/activity.ts:105 says "Wiping a computer deletes the machine those commands ran on, so leaving them on screen would describe something that no longer exists." Nothing in the tree calls it. The reset path runs setComputerStateMutationOptions (app/src/lib/computers/mutations.ts:12), whose onSuccess invalidates computerKeys.all and nothing else: the query cache is refreshed, the module-level store is not. The intent was written down and the one call site it needed was never added. The browsed set in the same module survives a reset for the same reason.
Reproduction
bun run dev against a deployment with a Bot that has a computer.- Open a channel with it and ask it to run
echo repro-marker-bravo.
- Open the pane beside the chat; the command and its output are listed under Activity.
- Without reloading, go to Admin → Computers, press Reset on that Bot, confirm.
- Return to the channel through the sidebar, not the address bar.
- The pane still lists the command from step 2.
Step 5 matters: a reload empties the store and hides this, which is likely why it has gone unnoticed.
Why it matters
Reset is the strong action on that screen. Its dialog says the profile is deleted, the Bot is signed out of every service, and it cannot be undone — an operator reaches for it when they want what the Bot did to be gone. The screen they land back on tells them it is still there.
The pane exists so nobody has to take the model's word for what happened on a machine holding somebody's logins. Showing a wiped machine's history without saying so is the one failure it cannot afford.
What a fix probably has to do
Call clearActivity(botId) when a reset succeeds — one line in onSuccess, guarded on action === "reset" so that stopping a browser, which keeps the profile and is meant to resume, leaves the history alone.
Worth deciding alongside it: a reset in one tab will not clear the pane in another, since the store is per-tab. That may be fine given the pane is documented as a live view of this session rather than a record. If it is not, the fact has to travel over the channel events socket, which is a larger change than the wiring gap.
Severity
Low. Nothing is broken and nothing is lost; the audit trail, which is the record, stays correct throughout. It is a surface asserting something about a machine that no longer exists, on the one screen whose purpose is telling an operator the truth about that machine.
Resetting a Bot's computer deletes its container profile and signs it out of everything, but the activity pane beside the chat goes on listing every command that ran on it. The pane presents commands and file operations from a wiped machine as though they were still true of the computer in front of you, and only a full page reload clears them.
What it looks like
After
Resetsucceeds —POST /api/computers/general-assistant/computers/resetreturns200, and acomputer.resetrow lands in the audit trail — navigating back to the channel still shows:That command ran on the profile the reset deleted. Nothing distinguishes it from a command that ran on the profile that exists now.
Why it happens
The activity store is a module-level map in the browser keyed by Bot id —
byComputerinapp/src/lib/computers/activity.ts:46, read byActivityLogand mounted as<ActivityLog computerId={agentId} />inapp/src/routes/_authed/_app/channel/$channelId.tsx:72. A reset replaces the container and the profile; it does not change the Bot id, so the map entry survives it.The function that would fix this exists and already carries this exact reasoning.
clearActivityatapp/src/lib/computers/activity.ts:105says "Wiping a computer deletes the machine those commands ran on, so leaving them on screen would describe something that no longer exists." Nothing in the tree calls it. The reset path runssetComputerStateMutationOptions(app/src/lib/computers/mutations.ts:12), whoseonSuccessinvalidatescomputerKeys.alland nothing else: the query cache is refreshed, the module-level store is not. The intent was written down and the one call site it needed was never added. Thebrowsedset in the same module survives a reset for the same reason.Reproduction
bun run devagainst a deployment with a Bot that has a computer.echo repro-marker-bravo.Step 5 matters: a reload empties the store and hides this, which is likely why it has gone unnoticed.
Why it matters
Reset is the strong action on that screen. Its dialog says the profile is deleted, the Bot is signed out of every service, and it cannot be undone — an operator reaches for it when they want what the Bot did to be gone. The screen they land back on tells them it is still there.
The pane exists so nobody has to take the model's word for what happened on a machine holding somebody's logins. Showing a wiped machine's history without saying so is the one failure it cannot afford.
What a fix probably has to do
Call
clearActivity(botId)when a reset succeeds — one line inonSuccess, guarded onaction === "reset"so that stopping a browser, which keeps the profile and is meant to resume, leaves the history alone.Worth deciding alongside it: a reset in one tab will not clear the pane in another, since the store is per-tab. That may be fine given the pane is documented as a live view of this session rather than a record. If it is not, the fact has to travel over the channel events socket, which is a larger change than the wiring gap.
Severity
Low. Nothing is broken and nothing is lost; the audit trail, which is the record, stays correct throughout. It is a surface asserting something about a machine that no longer exists, on the one screen whose purpose is telling an operator the truth about that machine.