A fixed-session worker is one harness-native session that an operating-system schedule checks for Kanban work. Set it up on the computer that will run it, from an authenticated interactive session in the intended repository. Installing a worker changes that computer's schedule and gives the unattended session broad access to its OS account and checkout; use only computers and repositories you trust. Claude runs with permission prompts bypassed; Codex runs with full filesystem access and no approval prompts. This is not a sandbox for untrusted tasks.
kanban board exists and is initialized. Read Set up a board first; a board is not a worker.Use the installed loom-kanban-worker setup workflow from an interactive, already-signed-in harness session. Select the board, repository, and harness, then review its confirmation before setup creates a session and native schedule. The first proof turn must succeed before the schedule is installed. Linux uses cron, macOS uses launchd, and Windows uses Task Scheduler. Do not open the daemon's fixed session interactively at the same time; use a separate session to inspect or publish work.
Claude workers use a long-lived setup token entered only through the worker workflow's hidden input; create it with Claude's setup-token flow when asked. Never paste it into a prompt, task, message, command argument, or log. Codex and OpenCode use their own sign-in on that computer; they do not use Claude's token. Do not switch to paid API authentication without explicit approval for that billed batch. A board store key is also secret and must never be copied into a task or message. For private Git access, configure it locally or follow the operator's separate approved credential-profile process.
After setup, check that the schedule exists and that the matching agent has a recent heartbeat. The identity is the harness plus its preserved session ID, not a process ID or hostname. Use the board's agent status for server-observed liveness and the worker workflow's status for the local schedule. A dormant worker may have unloaded its harness after an idle hour while retaining its schedule, enrollment, and session; that is normal.
stop pauses the current daemon process, but leaves the schedule and identity in place, so a later scheduled wake can start it again. Use the worker workflow's remove only when retiring a directly installed worker; it removes that local schedule and retires the board identity. Task and run history remains on the board. For a Fleet-managed worker, change its desired count through Fleet instead of removing it by hand.
On Windows, scheduled workers start only while their OS user is signed in; durmem does not store a Windows login password. See Run a Fleet for multi-computer desired state, or practice the second-computer flow in Tutorial 15.