jobbsok could not start on stock Windows. `.mcp.json` named `bash` as the
command, and the five entry points behind it reached for grep, sed, find, awk,
zip and unzip. `bootstrap.sh` built the virtualenv, so a Windows adopter could
not even reach an interpreter. Two adopters are waiting and neither is
guaranteed to be on macOS, so this is the install, not a rough edge.
The Python layer was already clean -- no /tmp, no /usr, no os.uname, no home
directory assumption -- so only the shell layer moved. Behaviour is carried
over unchanged; the deliberate exceptions are listed in docs/.
THE ONE OPEN DECISION, AND WHY IT WAS FORCED
How does .mcp.json start an interpreter without a POSIX shell, when it is
called python3 on macOS and python or py on Windows? Measured against the
installed CLI, not assumed:
- The plugin mcpServers stdio schema has NO platform-conditional form. A
config carrying invented windows/darwin/platform keys was accepted and the
keys were silently discarded -- it fails quietly, not loudly.
- ${VAR:-default} IS expanded, in command, args and env.
- ${VAR} without a default is not safe: unset, it is passed through
unexpanded, so the spawn would try to run a program named ${VAR}.
- Windows spawns with shell:false, so a .py path as command is out.
- No single literal works. On this Mac, python and py are not on PATH.
So the default form is the only lever the schema offers:
"${JOBBSOK_LAUNCH_PYTHON:-python3}". macOS and Linux keep working with nothing
set; Windows sets one variable and needs no shell.
A SECOND VARIABLE, NOT A REUSE OF JOBBSOK_PYTHON
JOBBSOK_PYTHON names the interpreter to SERVE on: the launcher treats it as an
explicit operator choice, so it wins over the bootstrapped virtualenv. A
Windows adopter setting it merely to spell `python` would silently bypass that
virtualenv and serve WITHOUT the ingestion guard. JOBBSOK_LAUNCH_PYTHON only
says how to start the launcher. A test asserts the two never collapse into one.
O4 IS LEFT STANDING
The launcher still gates on the interpreter's version rather than on the guard
being importable. That is the shell version's semantics carried over on
purpose: harmless while nothing writes, a defect from M2, and an M2 decision.
VERIFY
- pytest tests/ -> 124 passed, exit 0 (was 112)
- grep -c '"command": "bash"' .mcp.json -> 0
- git ls-files 'scripts/*.sh' -> 0
- README install block names Windows, and neither WSL nor Git Bash
- server started end to end exactly as .mcp.json expands, and answered
initialize and tools/list
- the ported probe checker reproduces the shell version's output and exits 0
NOT MEASURED, AND NOT ASSUMED
Nothing here has ever run on Windows. Whether Cowork on Windows bridges to a
host-side stdio MCP as it does on this Mac is unmeasured -- docs/cowork-probe.md
covered macOS only. docs/cross-platform-port.md says what a Windows probe would
have to measure, and records two findings left deliberately untouched.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The install block was written under the assumption that this project has no
users but its author. It has two, so every claim in it is now load-bearing.
Three corrections, each measured rather than reasoned:
- The guard's host is reachable. `git.fromaitochitta.com` resolves to a public
address, serves a valid certificate and answers `git ls-remote` with no
credentials, no global git config and no terminal prompt; a non-existent
repository on the same host fails, so the query can distinguish. A full
anonymous `pip install` of the pinned `v1.3.0` builds a wheel and imports at
1.3.0. The old text told a third party they probably could not reach it.
- The Claude Code route did not work. `claude plugin install` resolves only
through a marketplace and `jobbsok` is not among the catalog's twelve
plugins, so the documented command failed at its first step. It is marked as
landing with milestone 2 instead of being printed as if it worked.
- Windows is named as unsupported, with the specific reason: the entry points
are shell scripts and `.mcp.json` starts the tool server through `bash`. The
Python underneath is already platform-clean, so the gap is packaging.
Prerequisites are stated up front, with a preflight command that needs nothing
installed, because an adopter should learn about a blocked network before
building a virtualenv rather than after.
Outside Step 16's Files list, and so a separate commit rather than part of the
pinned Cowork-verification commit, following the precedent of 90ef620.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
