WorkBay: State for Coding Agents

Why I built it
I move coding work between Claude Code and Codex fairly often. I also use Cursor, grok and Copilot when one of them suits a particular job.
Git makes that easy for the code. The surrounding task state is harder to move.
A review comment may exist only in a chat. The reason I rejected an approach may be buried fifty messages back. A new session can inspect the repository, but it has no direct record of those decisions unless I wrote them down somewhere.
I built WorkBay to write that record into the project.
What it keeps
WorkBay creates a SQLite database at .task-state/handoff.db.
The current task lives there with its branch. Review findings have their own records. Decisions can refer to the commit where they were made. Test results can refer to the code they ran against.
The database is available over MCP, so more than one coding tool can read it.
I keep the commands consistent between tools from a shared manifest. /scope, for example, turns a loose idea into a bounded task. /branch-review records findings from a review. The repository contains the full command set.
Changing tools
Suppose I stop a task in Claude Code and open the same repository in Codex.
WorkBay can load the active task from the database. An open review finding is still open. A recorded decision is still attached to the task that produced it.
That saves me from reconstructing the task from chat history.
Some re-entry remains. Codex may have different tools available than Claude Code. It may also need an explanation of code that was never entered into WorkBay. The database only knows what was recorded in it.
This is useful after context compaction too. I can reload the task record instead of relying entirely on a prose recap of an earlier session.
Review findings
I wanted review comments to remain useful after the reviewing session ended.
A WorkBay finding has a status. It can also carry commit provenance.
If another agent later addresses the finding, I can associate that change with the record. The close checks then read the stored state before the task is finished.
WorkBay also installs Git hooks for parts of this process. I use them to catch edits on main and to enforce the branch rules used by the project.
The hooks govern the normal development path. Shell access can change the hook configuration or bypass some checks, so I treat them as development safeguards rather than access control.
Sending out bounded work
/offload is for implementation work that I have already reduced to a small, explicit task.
It creates an isolated worktree and sends the task to the backend I selected. I give that run a token budget.
The worker can commit a result. Merge authority stays with the parent task, where I can inspect the diff first.
I use this for changes that are mechanical or already well specified. Architecture work usually stays in the main session because too much of the relevant context is implicit.
If a requested backend is unavailable, the dispatch stops. It does not choose another backend on my behalf.
Semantic lookup
After a project has accumulated enough history, exact text search becomes less useful.
WorkBay can optionally create embeddings for rows already stored in its database. On session load, those embeddings help find older records that are related in meaning even when the wording differs.
The source material remains the structured WorkBay data.
On a short project I usually do not need this. It becomes more useful when a task survives many sessions.
What I use it for
WorkBay is project plumbing for my own agent-assisted development process.
Its job is fairly narrow: preserve enough recorded state that I can reopen a task without treating the previous chat as the sole source of history.
It does not capture everything a model was thinking. I do not expect it to make different models behave alike either.
What it gives me is a record I can inspect later: which task was active, what review work remained, and which commits were involved.
Installation details and the current schema are in the WorkBay repository.