workbite

WorkBite installs and opens Work Stack (organizes the work) and StackBite (gets it moving) as one native suite.

Launcher 0.1.24 pins qualified Windows x64 and Linux x64 native archives. TypeScript TUI remains 1.0.38 and the embedded StackBite is 0.5.39. Both archives use build source ba44d63cb89c9f979c236a2df6a7dcf73228a129, tree 15c07e0d5de33440422210675855c73c8de8a0b9. Their actual archive hashes, embedded bundle digests and sizes are sealed in release.json for v0.1.24 in Shinick-Han/WorkBite-releases. Publication, registry delivery and installed runtime handover are separately verified maintainer operations. The maintainer uses the selected manual publication path because hosted Actions quota is exhausted; no hosted CI/OIDC success is claimed. It opens the familiar TypeScript Work Stack UI by default, which has one Tasks workbench: switch Focus/Table/Board without losing your selected Task, open its persistent Room's plain terminal, and control it beside or below the Tasks. A compact terminal action is the default Task workspace entry; advanced Run deployment, history and result review remain available. Horizontal Seat tabs and the vertical Seat list share selection, input state and one native terminal host; switching presentation does not launch or stop a Seat. Use F6 to move focus, Ctrl+B to hide the sidebar, Alt+Shift+L to switch layouts, Alt+Shift+arrows to resize, and Alt+Shift+Z to expand the active pane. Existing Runs and Seats remain available while navigating. Cursor and Grok remain raw native providers in opted-in Rooms (you approve their trust; native lifecycle, completion and resume remain unsupported/unqualified). The unified Rust UI stays an explicit alternative per open: workbite open --frontend rust (or bare workbite --frontend rust). Either frontend reuses the same owner and StackBite backend; the choice is not saved. Leaving the view or closing the UI keeps the agent running, and Task completion stays an explicit action.

The 0.1.24 pair passed independent archive/runtime review: all 17 Windows probes, all 12 Linux ELF version-needs audits at GLIBC <= 2.28, and 29 AlmaLinux 8.10 userspace probes. Fresh bounded lifecycle source checks passed on Windows and Linux; Windows-only checks skipped on Linux remain explicit. These checks do not claim a real provider turn, interactive-screen acceptance, booted AlmaLinux, baseline CPU, SSH/VM, NFS or physical Phone behavior. Linux Phone is unsupported. See the 0.1.24 release notes and qualification record for pins and limits.

The Rust frontend highlights the active Room and Seat with a background. Optional Claude/Codex lifecycle hooks add observed work status for CLIs started manually inside shell Seats. Stop means idle, never verified completion. Hook installation and an existing CLI's normal restart/resume may be required; Codex retains its normal hook trust review. Current owners and Seats remain on their existing runtime until a safe operator handover; updates do not stop them or clear unknown startup records automatically.

The candidate keeps a stable Seat across explicit shell restarts, with a fresh generation and no inferred previous CLI/provider resume. Stop retains the Seat; removal targets a confirmed finalized execution and retains bounded history. History labels distinguish available, truncated, failed and unavailable capture. The canonical Task Room includes older bound Rooms and truthful running/waiting/exited/unknown summaries. Human terminals default to pinned; verified spawned children default to temporary, with recorded parent provenance. Bulk cleanup preserves pinned, live, stale and unknown targets; explicit removal of a finalized pinned Seat is a separate user choice.

Arrow navigation now reaches the sidebar, header, Tasks, Seat previews and visible execution actions. Sidebar Up/Down previews; Enter/Space commits; Right returns to content. Execution Right enters actions and Left returns to Seats/Tasks. Pickers distinguish choices from filter text; forms and confirmations show focused buttons, including default Cancel. Hidden or clipped controls must be revealed before activation; arrow movement alone does not dispatch actions. Enter or click on a Seat requests its exact writer claim; input begins only after acknowledgement. Pending and granted raw CLI modes keep keys in the terminal path without replay; one Ctrl+] returns to the UI. Text fields keep caret arrows and literal Space; multiline Enter stays newline. Existing F6, Ctrl+B, Alt+Shift+Z and command shortcuts remain available. Native semantic instructions and mobile terminals remain unsupported and unadvertised.

Mobile execution is source-qualified only: explicit PC execution permission is separate from read pairing; deployment uses the PC's saved provider, folder, model and effort defaults. A lost acknowledgement keeps the original operation UUID for reconnect/status observation without replay. Offline or revoked requests cannot dispatch. The joined 13-scenario production-adapter acceptance passed with inert execution/terminal boundaries; it is not physical keyboard, native terminal, physical-phone or packaged runtime proof. These source paths do not advertise mobile execution as an installed Phone feature.

workbite update explicitly updates a global npm launcher to official npm latest and stages its verified native suite. Local/npx copies print manual guidance instead. Current latest is a no-op. Running owners, Seats and Phone stay on their existing runtime; complete operator handover before opening the new one. A failure can leave the launcher installed without its suite: inspect workbite --version, then resolve the error and run workbite install and workbite check. Never replay an unknown npm install without inspecting it.

npm install -g [email protected]                             # only after registry publication and public-asset verification
workbite install
workbite open --workspace /abs/path/new-folder --init      # first time, once
workbite                                                   # afterwards (TypeScript UI)
workbite --frontend rust                                   # unified Rust UI with 9 Execution

Node.js 20+ on Windows x64 or Linux x64 (glibc 2.28+).

• workbite install downloads the pinned bundle for your platform from github.com/Shinick-Han/WorkBite-releases, verifies its size and SHA-256 and every file listed in its bundle.json, and installs it into an immutable per-user version folder. No auto-update, no install scripts, no dependencies.
• workbite check re-verifies installed bundle integrity without downloading; it does not test backend health, workspace admission or UI behavior.
• workbite open --workspace ABS [--init] [--no-ui] [--frontend typescript|rust] starts or reuses the workspace's Work Stack owner and a StackBite backend (only processes it can prove it started), then runs the TypeScript Work Stack UI, or the unified Rust UI with --frontend rust (0.1.4+ execution bundle only; an older bundle refuses it before starting anything). Backends keep running after the UI exits.
• workbite (or workbite open without --workspace) reopens the last workspace that opened successfully; an explicit --workspace always wins. It refuses, starting nothing, if that workspace is missing, moved or its workspace.json id changed, and never picks another folder by itself. --init always needs an explicit --workspace.
• Each backend's startup record (private token, launch id, port) is saved in the state folder before the process is started. A later open reuses that same attempt once it authenticates (also after a slow start), and otherwise refuses. Unreadable/invalid records remain untouched; an unreachable process is not assumed stopped. The unreleased source's narrow archival path requires trusted same-host previous-boot evidence for eligible owner/backend records. It does not resolve foreign hosts or native intents. Diagnose the exact host/boot, workspace, backend and native intent before operator handover. Age or a missing local PID cannot establish that a process on another NFS client has stopped; preserve uncertain records.

WorkBite keeps its own state (%LOCALAPPDATA%\WorkBite on Windows, ~/.local/share/workbite and ~/.local/state/workbite on Linux; override with absolute WORKBITE_HOME / WORKBITE_STATE_DIR) and never touches separately installed Work Stack or StackBite apps, their state or ports. It never approves provider trust or starts paid agents by itself.

Startup diagnostics include workbite status [--json], workbite doctor [--json] and workbite recover --dry-run [--json]. They inspect evidence and plan only: no process starts/stops, record reset, native intent repair or migration. open --no-ui does start/reuse the backend stack (including native selection for v2) and prints JSON, but never launches or validates the foreground UI. Startup stage messages distinguish that UI launch from backend readiness; the launcher continues waiting while the UI runs. Full installed-file hashing still occurs on reuse, so these changes do not promise faster opens.

For NFS shared homes, configure the existing absolute WORKBITE_STATE_DIR override to a distinct host-local runtime directory per host after coordinating any existing owners and active Seats. This does not move old state or permit parallel writers to one shared workspace. WORKBITE_HOME separately overrides the installation root (app/ beneath it); changing it is not a universal tar fix. See the source repository's startup troubleshooting guide for tcsh setenv examples, failure diagnosis, bounded tar stderr and safe handover requirements. Keep workspace locks and unknown native intents intact.

Coding agents read and record Tasks of a workspace whose owner workbite open already runs; nothing is started for them:

workbite agent status                                    # bound workspace path + UUID
workbite agent --workspace ABS --workspace-uid UUID context --task T-0001
workbite agent --workspace ABS --workspace-uid UUID tasks create --intent-id ID --input-file FILE
workbite mcp --workspace ABS --workspace-uid UUID         # MCP stdio server

Writes (tasks create, tasks update, checkpoint) always need the explicit --workspace + --workspace-uid pair. workbite mcp binds one workspace when it starts. The workbite-native agent skill shipped in this package (skills/workbite-native/) describes the commands, packets and recovery rules.

In a Task-bound plain terminal, manually started CLIs can discover their assigned Task through an already enabled WorkBite MCP server. The inherited binding verifies workspace and Task identity, snapshot digest, Room, Seat and the current live generation before exposing context. A changed or unverifiable assignment refuses discovery. Standalone/unbound terminals retain the explicit workspace/context path. WorkBite does not enable MCP or configure providers automatically; source fixture checks do not prove an actual provider turn.

The candidate retains the repair for initial Task Room capability discovery and recovery notices after overlapping reads. Task Room inventory is filtered to the requested Task's Rooms before runtime inventory is read. Selecting a Task continues to create no Room, Seat or provider.

The candidate retains Connect agent in Task Execution (a), the global 9 Execution monitor and launch picker (+), clickable controls and scoped command palettes (:). Claude Code, Codex, Cursor and Grok Build use their official CLI login and credential storage. Missing CLIs offer install guides; nothing installs automatically. Connecting preserves the Task/draft, folder, instructions and watched Run/Seat, and never deploys or changes Task status. Selection rechecks current authentication and launch readiness; an old login receipt cannot establish current authentication.

Codex discovers model IDs and supported effort choices with a bounded cache; CLI defaults remain selectable and unsupported saved choices stay visible. An official Grok login success marker can show provider_login_completed_status_unverified; it does not show a connected badge or prove current CLI authentication. Generic exit zero and refresh alone do not prove login. No authoritative local Grok auth-status probe is qualified; launch-ready CLI settings can be selected explicitly with that label. Automated login process ownership is qualified on Windows only; POSIX automated connection remains refused pending cleanup qualification. Source checks used disposable fixtures, with no live account login, browser completion, account-entitlement proof or paid provider turn acceptance. See the source acceptance record.

The Windows candidate retains the read-only phone companion pilot from 0.1.14. Linux Phone support remains unsupported; paired releases do not imply identical platform capabilities. Phone actions preserve their selected target during status reads, show pending work and reuse the managed Windows helper within actions. Pairing links retain their complete URL. New hosts supply a compact pairing URL and an inline TUI QR with an enlarged view; this path creates no PNG and opens no external viewer automatically. Small terminals show size guidance instead of a partial QR. Link opening and supported image actions remain explicit choices; older hosts retain their compatibility path. QR opening has an explicit Edge alternative. A successful system handoff does not establish that a browser or viewer rendered the target. Open Settings with ,, select Phone, enable it, then pair using the expiring QR and compare the complete fingerprint before approving on the PC. Remembered browsers can reconnect; devices can be revoked. Initial PC enrollment requires an operator invitation through the supported embedding/bootstrap surface; this release does not include a public invitation-entry UI. The hosted relay needs no user domain or Cloudflare client. CurrentUser DPAPI on local NTFS is required. The retained read-only Phone pilot does not support Task writes, deployment, terminal input, replies, notifications or background connectivity. The PC must remain online.

This package is UNLICENSED (all rights reserved). Third-party licenses ship in each bundle's licenses/ folder.

The candidate retains the 0.1.16 Phone control-file sharing fix and existing protected-store and OS lease checks. Hosted mobile assets must accept both old object offers and compact tuples before the new PC emitter is installed. Source tests and rendered fixtures do not qualify physical phone cameras, actual terminal fonts, LTE or background behavior.