TaskWindow v0.2.7

Extension and daemon. Coming from 0.2.6: taskwindow update.

Changed

One session, one tab group. A tab group exists to hold every tab of one
job, but agents were getting a group per tab: at the moment it calls
tabs_create an agent has its attention on the sub-task in front of it, so it
named that — "Glass bezel check", "Masked band check" — and each name made
its own group of one. The name is now read once, on the first call of a
session, and fixed: every later tab joins that group, and a task passed
anyway is reported back in the result instead of starting a second group. The
tool now asks for the name of the whole job, not of the page about to open.

Every result restates your session token. The token was named once, in the
first tabs_create result, at the start of a session meant to run for a whole
job — so it was exactly the detail an agent loses as its context is
compacted, and the next tabs_create without it counted as a different
session and opened a second tab group. Every session-scoped result now ends
with a session: ... line, so the token an agent needs is always in what it
just read.

Added

Short tasks clean up after themselves. Naming a task in tabs_create now
also asks longRunning: might this job need more than an hour? Say false
and the group closes itself, tabs and all, once it has been idle for an hour,
so a finished lookup no longer sits in the TaskWindow window for a month. Say
true and it keeps the 30-day lifetime. The answer is required on the call
that names the task — the first of a session. To revise it later, pass
longRunning on its own; passed alongside a task, it is ignored with the
name it came with, so a stray sub-task name can never cut a whole job's group
down to the one-hour lifetime. A group whose tab you are reading is never
closed, and groups created before this release keep the 30-day lifetime.

Fixed

Task groups stay in the agent's window. The first tab of every new task was
yanked into whatever Chrome window you were last looking at, leaving the agent
window holding nothing but its pinned anchor. Creating a tab group without
naming a window puts it in Chrome's current window — for an extension service
worker, the window you last focused — and Chrome moves the tab there to join
it. New groups now say which window they belong to.

And the agent window is found by its anchor, not by its groups. The fix
above governs new groups; it could not bring back the groups the bug had
already parked in your window, because the lookup for "the agent's window"
answered with wherever the most recent group happened to sit — your window,
authoritatively. So a brand-new task kept opening there too. The pinned
workspace tab now identifies the agent window; groups only break a tie between
two anchored windows, or stand in when no anchor is left. "Use this window for
the agent" moves the anchor along with the groups, which empties the old agent
window and lets Chrome close it. Nothing to do after updating: the next task
opens where the anchor is.

Nothing ever brings a tab forward. 0.2.6 still made a tab visible before
mouse input, on the belief that a hidden tab never acknowledges the event, and
failed the call when that tab was behind yours — which agents then worked
around by closing tabs or clicking through page scripts. Checked in Chrome:
click, wheel scroll and typing over the DevTools protocol all land in a tab
that is not its window's active tab, and it stays that way. The activation and
the "behind another tab" error are gone.

Install

Run npm install -g taskwindow@latest, then taskwindow install. The guided installer configures the daemon and selected coding agents, downloads the extension, opens Chrome, and pairs automatically after you load the unpacked folder.

Manual archives are attached below. Run taskwindow doctor for connection diagnostics or taskwindow pair for manual recovery.

See the README for the full guide.