Shob: a TypeScript agent workspace that wraps parallel sessions, permissions and Git state

The problem Shob targets is session sprawl, not code generation

Most coding agents assume one conversation, one task, one terminal. Real work on a repository does not look like that. A bug fix, a test run, a documentation pass and a refactor can all be in flight at once, and each one wants its own context window, its own approval prompts and its own view of what changed on disk. The common workaround is to open several terminal tabs and keep track of which agent touched which file. Shob's stated goal is to collapse that into a single environment: the README describes running "multiple AI agents simultaneously within the same project" for bug fixes, testing, documentation, refactoring and feature work. The audience is developers, students, freelancers, startups and teams, which is a broad claim, and the vision section frames affordability as the differentiator rather than capability. That framing matters, because the feature list is about coordination and oversight, not about the quality of the underlying model output. Shob does not appear to be a model. It is a workspace that sits around agents you already use, and the topic list (anthropic, claude-code, codex-cli, cursor-ai, opencode, mcp) suggests the intent is to host several of them rather than replace any one. If your problem is that a single agent produces weak code, Shob is not aimed at you. If your problem is that four agents are producing code and you cannot see what any of them is doing, that is the gap it claims to fill.

What the README actually specifies about the mechanism

This is where the material runs out, and it is worth being blunt about it. The README lists six capabilities: parallel sessions, a permission system, Git integration, subagent delegation, live task tracking, and terminal plus diff preview. It does not describe the architecture behind any of them. There is no diagram, no description of how a session is isolated, no statement about whether parallel agents share a filesystem or operate on separate worktrees, and no explanation of how conflicts between two agents editing the same file are resolved. The permission system is described as letting you "review and approve commands, file access, and code changes before they happen," which tells you the gate exists and roughly what it covers, but not whether approvals are per-session, per-command-pattern, or persisted across runs. Subagent delegation is described as breaking large tasks into smaller pieces and receiving "consolidated results from a single workspace," which implies a parent agent fans work out to children and merges their output, but the merge semantics are not stated. Live task tracking and the diff preview are UI-level claims; the README says you can "inspect code changes before accepting them," so acceptance appears to be a distinct step from generation. The Git integration is the most concrete item: Shob "understands your repository, active branch, and local changes." Read literally, that is read access to repository state. It does not say Shob creates branches, commits, or stashes, and you should not assume it does. For an engineer deciding whether to adopt, the honest summary is that the mechanism is asserted rather than documented, and the repository is the only place that could settle it.

Getting it running: what the README gives you and what it withholds

The Get Started section contains one link to the GitHub repository and a request to star the project. There is no install command, no npm or pnpm invocation, no global binary name, no Docker image, no configuration file example, and no environment variable listing. The homepage at shob.olova.dev is referenced in the repository metadata but its contents are not reproduced in the material available here, so any setup instructions it carries cannot be verified from this source. What can be confirmed is the surrounding facts: the primary language is TypeScript, the default branch is main, the licence is MIT, and the most recent release is v0.0.97 dated 31 July 2026, preceded by v0.0.96 the same day and v0.0.95 on 19 July 2026. If you want to evaluate Shob, the practical path is to open the repository, read the release notes for v0.0.97, and look for a package manifest or a bin entry in package.json, which would tell you the command name. Until you find that, any command you type is a guess. This is not a criticism of the project's ambition, but it is a real cost: an undocumented install path means the first hour of evaluation is spent reverse-engineering rather than testing. The README's own status line says Shob is "currently in Beta," which is consistent with that gap.

Beta release cadence and what it implies for upgrades

Three releases in roughly five weeks, two of them on the same day, is a normal pattern for a project still finding its shape. It also means the surface you integrate against is likely to move. The version numbers are all in the 0.0.x range, so by the usual reading of semantic versioning there is no stability promise at all: v0.0.97 to v0.0.98 may change behaviour without a major bump. For a tool that sits between you and file writes, that matters more than it would for a linter. The permission system and the diff preview are exactly the components you would want frozen, and there is no changelog in the supplied material describing what changed between v0.0.95 and v0.0.97. The maintenance cost is therefore not the licence, which is MIT and permissive, but the attention required to keep pace with patch releases. MIT means you can fork, modify and redistribute, including commercially, provided the copyright notice and licence text are preserved. That is a genuine advantage for a tool you might want to adapt. It does not tell you anything about whether the project will still be maintained in a year, and the absence of a stated governance model or roadmap beyond the vision paragraph leaves that open. If you pin a version, pin it deliberately and read the diff before moving.

Where Shob is the wrong tool

The permission system is the feature most likely to disappoint in practice, and the README gives no detail that would let you predict how. A gate that asks you to approve "commands, file access, and code changes" is only useful if the granularity matches your risk tolerance. If every file read triggers a prompt, the gate becomes noise and you will start approving without reading, which is worse than no gate because it creates the appearance of oversight. If the gate is coarse enough to be usable, it may not catch the specific thing you cared about. The README does not say which it is, and that is the single question I would want answered before running Shob against a repository with anything sensitive in it. The second case where Shob is the wrong tool is single-task work. If you are fixing one bug in one file, the overhead of a workspace with parallel sessions, subagent delegation and live tracking buys you nothing, and a plain single-session CLI agent will be faster to start and easier to reason about. The third is any environment where you cannot inspect the code first. Shob is beta software with an undocumented install path that, by its own description, executes commands and modifies files under an approval model whose thresholds are unspecified. Running it against a production checkout before reading the permission implementation is not a reasonable risk to take.

How this differs from a single-session agent CLI

The obvious comparison is a single-agent command-line tool such as Claude Code or Codex CLI, both of which appear in Shob's topic list, which suggests Shob is designed to sit alongside them rather than compete. The difference in approach is structural. A single-session CLI agent owns one conversation and one working context; when you want a second task, you start a second process, and the two processes know nothing about each other. Shob's claim is that the workspace holds the shared state: the repository, the active branch, the local changes, and the set of running tasks. That is a different bet. It assumes the coordination layer is the scarce resource, not the model. Whether that bet pays off depends on something the README does not address, which is conflict handling. Two agents editing the same file in the same working tree is the failure mode that a shared workspace introduces and a set of independent terminals does not, because in the independent case you at least see two separate diffs. Shob's diff preview and approval step are presumably the answer, but the README does not describe how a rejected diff is rolled back or whether an approved diff from one session can invalidate the context of another. That is the question to press on. The MCP topic also hints at tool-protocol integration, which would let Shob expose or consume external tools, but again the README does not describe it, so treat it as a direction rather than a documented capability.

Editorial conclusion

Shob is worth a look if you already drive more than one AI coding session per repository and you want the approval prompt and the diff view in the same window rather than spread across terminals. It is the wrong choice if you need a documented install path, published config schema, or a stable interface today: the README ships no npm command, no config keys and no environment variables, and the release history shows three patch versions inside July 2026. Before adopting, open the repository and confirm three things for yourself: whether a published package exists for the v0.0.97 tag, which files the permission system actually gates, and whether the Git integration only reads branch and working-tree state or also writes to it. If those three answers are not in the repo, treat Shob as a prototype to read rather than a tool to depend on.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. shobcoder/shob on GitHub