zcoder.zsh v0.8.0 — External workers and runtime hardening

zcoder.zsh v0.8.0

v0.8.0 adds explicitly authorized workspace-editing workers for external coding
harnesses, makes model tool execution and transport recovery more reliable, and
hardens Zsh file, terminal, temporary-storage, and shutdown boundaries.

Highlights

External coding workers

• /claude!, /codex!, /agy!, and /opencode! run one explicitly
  workspace-editing harness invocation, while the commands without ! remain
  read-only consultations.
• Each provider uses its native edit mode or sandbox. Worker prompts confine
  changes to the selected workspace and withhold unrelated authority such as
  installing, deploying, committing, pushing, or publishing.
• Worker reports use distinct transcript roles and enter Ollama context as
  untrusted reports. The main agent is told to inspect the current workspace
  instead of accepting a worker's claims as proof.
• Editing workers are disabled in the sysadmin profile because their internal
  commands cannot participate in zcoder's mandatory per-command approval flow.
• Local and remote availability discovery now identifies which harness CLIs
  exist on the host that owns the workspace. Protocol-1 remote peers remain
  compatible when they omit the new capability field.

More reliable model and tool execution

• Multiple emitted tool calls execute sequentially in model order, including
  edit-and-verify sequences. Every call retains its own argument validation,
  workspace boundary, safety guard, command approval, result, and error.
• finish remains exclusive turn control: mixing it with work rejects only the
  invalid completion call instead of discarding already completed work.
• The system prompt, tool schema, and rejection output now share one exact
  unified-diff contract with valid and invalid examples, numeric hunk guidance,
  and a focused retry path after malformed patches.
• Ollama payloads contain exactly one leading system record. Runtime recovery
  and external-harness context use template-safe user records, including when
  older saved sessions contain mid-conversation system entries.
• A transient connection failure before any Ollama response receives one
  bounded replay. Response timeouts remain non-retryable so a long generation
  is not silently restarted from scratch.

Native Zsh runtime hardening

• HTTP requests, remote responses, debug records, and workspace file writes now
  handle partial syswrite results until every byte is written or a real error
  occurs.
• Command output, patch data, asynchronous HTTP results, delegate exchanges,
  and MCP broker files share an atomically created process-private runtime
  directory with group and other access disabled.
• Workspace writes reject dangling symlinks and non-regular targets, then open
  the validated final path with nofollow. Debug logs likewise reject symlink
  targets, keep a private owned descriptor, and enforce owner-only permissions.
• Model, tool, and project text printed directly to a terminal renders control
  bytes visibly, preventing OSC, escape, carriage-return, and backspace data
  from altering approval or transcript displays. Redirected output remains
  exact for scripts.
• Signal traps now preserve conventional interrupt and termination statuses,
  prevent cleanup re-entry, close owned descriptors, reap workers, and remove
  private runtime storage once.

Compatibility and verification

• Zsh 5.8 or newer
• Ollama with a tool-capable model
• Existing session, MCP, authentication, and protocol-1 remote formats remain
  compatible
• 730 automated tests passing, including partial writes, private runtime
  permissions, terminal controls, dangling symlinks, debug-log confinement,
  external workers, remote capability discovery, multi-call execution, patch
  recovery, and transport replay
• CLI smoke checks for version, resolved project instructions, Agent Skills,
  and MCP registry listing

For the full documentation, see the documentation index.

zcoder.zsh v0.7.0 — Model readiness and remote sessions

zcoder.zsh v0.7.0

v0.7.0 makes local and remote model startup predictable, turns remote jobs
into browsable persistent sessions, and improves compatibility with models that
do not follow one narrow tool-calling pattern. The release also strengthens
loop recovery and fixes command approval and Codex consultation failures.

Highlights

Model readiness and warm-up

• The TUI starts a disposable Ollama warm-up request containing the resolved
  system prompt and project instructions, and shows Warming Up until the
  model is ready.
• Warm-up never enters the saved conversation or user-message ledger, and a
  real prompt safely supersedes an unfinished local warm-up.
• Remote clients check whether the server's configured model is resident when
  they connect and again before each prompt. If another model displaced it,
  the request waits while the server reloads the correct model.
• Remote warm-up workers detach inherited sockets, refresh the allocated
  context size after loading, and remain compatible with older servers that do
  not expose model-readiness status.
• --no-warmup remains available when eager local loading is undesirable.

Persistent remote sessions

• Remote servers now expose scoped session summaries and persisted transcripts
  to authenticated clients. The TUI session sidebar lists server-owned jobs,
  marks the selected and active jobs, and can load an older transcript.
• Local and remote interactive launches start with a fresh conversation instead
  of silently resuming the latest used session. An untouched blank session is
  reused to avoid accumulating empty jobs, while older sessions remain
  explicitly selectable.
• Remote prompts can be queued during a model warm-up race, cancelled before
  execution, and started exactly once when readiness changes.
• Remote command approval no longer deadlocks while the worker is waiting for
  the client's one-use approval response.

Broader model and tool-call compatibility

• LFM-family planner envelopes, alternate action fields, foreign tool-call
  shapes, and shell-command plans are normalized into the native tool pipeline.
  Promoted commands still pass workspace checks, safety guards, and command
  approval.
• False tool-unavailable responses, malformed planner output, and empty
  responses receive bounded recovery turns instead of being accepted as task
  completion.
• Ollama responses containing multiple independent reads or run_command
  calls are now handled as multi-call turns. zcoder dispatches them in model
  order, applies the configured command approval policy to each command, and
  returns every result to the model.
• Batches containing edits, Skill activation, finish, unknown tools, or MCP
  tools without side-effect metadata still fail before partial execution.

Loop recovery and consultations

• Repeated tool outcomes and short alternating cycles now trigger one explicit,
  final recovery turn. A materially different action clears the warning; a
  repeated violating round is rejected before execution and stops the run.
• The agent loop no longer has a fixed model-turn ceiling while work continues
  to make progress.
• /codex now places the global approval option before codex exec, matching
  current Codex CLI argument parsing while retaining its read-only consultation
  sandbox.

Compatibility and verification

• Zsh 5.8 or newer
• Ollama with a tool-capable model
• Existing saved-session and remote authentication formats remain compatible
• New remote readiness and session endpoints degrade safely when connecting to
  an older server
• 640 automated tests passing, including model warm-up, remote session browsing,
  queued prompts, LFM normalization, loop recovery, Codex delegation, and
  serialized multi-call command dispatch
• Live protocol verification against Ollama 0.32.15 with
  kat-coder-2.5-dev-mtp-q4-128k

For the full documentation, see the documentation index.

zcoder.zsh v0.6.0 — Performance and hardening

zcoder.zsh v0.6.0

v0.6.0 is a performance and hardening release. The Zsh runtime was profiled
end to end and its hot paths rewritten around native C-speed primitives, with
no change in behavior; parsing became resilient to malformed model output, the
remote token file is now required to be private, and libraries load lazily by
mode.

Highlights

Performance overhaul

Zsh scalar subscripting rescans a string from its start on every access, which
made several per-character loops quadratic. The hot paths now use character
arrays, subscript-pattern searches, and split+join transforms instead:

• Parsing a typical 120 KB Ollama response dropped from roughly 15 seconds to
  under 30 milliseconds; a 12 KB response from 193 ms to under 8 ms.
• JSON string encoding of large histories dropped from 205 ms to 12 ms per
  120 KB message, and skipped members are no longer re-serialized.
• The multiline prompt editor lays out large pasted prompts arithmetically:
  under 1 ms per keystroke where a 6 KB paste previously cost 68 ms.
• The transcript renderer caches its output: appends render only the new
  message, and scrolling repaints without re-rendering the conversation.
• Session saves are incremental, writing only new records: about 1 ms per turn
  on a 340-message session instead of 25 ms and growing with history.
• Request payload assembly joins message arrays at C speed instead of
  re-copying the growing payload per message.

Every rewritten primitive was verified byte-for-byte against the previous
implementation with differential fuzzing across roughly twelve thousand
randomized cases, including multibyte text, control characters, and malformed
input.

Resilient unicode decoding

• An unpaired UTF-16 surrogate escape in model output previously aborted the
  whole process mid-parse. Each unpairable surrogate now decodes to the
  Unicode replacement character (U+FFFD) and parsing continues.
• Valid surrogate pairs, all simple escapes, and every error message are
  unchanged, and a containment guard prevents any locale-specific encoding
  failure from terminating the session.

Private remote token files

• Both --server and --connect now refuse to start unless the token file is
  owned by the invoking user and carries no group or other permission bits
  (chmod 600; a stricter read-only 400 also works).
• The refusal happens before any socket is opened and names the exact
  chmod 600 fix. The documented umask 077 setup already produces a
  compliant file.

Faster, leaner launch

• Libraries load once, on demand: the remote transport loads only when a
  remote mode is selected, and the external-delegate harnesses load on the
  first consultation command.
• zcoder.zsh mcp ... dispatches through a fast path that loads only the
  configuration and protocol libraries.
• A new make compile target precompiles the libraries to .zwc wordcode,
  roughly halving launch time. Zsh ignores a stale .zwc, so recompiling is
  an optimization, never a correctness requirement; make clean removes the
  compiled files.

Compatibility and verification

• Zsh 5.8 or newer
• Ollama with a tool-capable model
• 472 automated tests passing, including new coverage for surrogate decoding
  and token-file permissions
• Differential fuzzing of the rewritten JSON tokenizer, encoder, line wrapper,
  and prompt layout against their previous implementations
• Live remote smoke checks: authenticated /v1/hello, unauthenticated
  rejection, and launch refusal on permissive token files

No configuration, session, or protocol formats changed; existing sessions and
remote setups continue to work unchanged.

For the full documentation, see the documentation index.

zcoder.zsh v0.5.0

zcoder.zsh v0.5.0

v0.5.0 introduces a complete remote-agent architecture, allowing zcoder to run
beside an Ollama model and workspace on another machine while its terminal UI
remains local.

Highlights

Remote-agent server

• Run zcoder headlessly with --server NAME, --port, and --token-file.
• Connect the normal TUI or a one-shot client with --connect HOST.
• Keep model inference, conversation state, workspace access, project guidance,
  Agent Skills, MCP servers, file operations, patches, and shell execution on
  the remote machine.
• Deliver assistant messages, reasoning, tool results, status changes, and turn
  completion as ordered HTTP events.
• Forward exact shell-command approval requests to the local client with
  one-use approval identifiers and a fail-closed timeout.
• Cancel remote turns with Escape and reject overlapping turns with a clear
  busy response.
• Preserve one isolated conversation per named server across process restarts.
• Prevent duplicate processes from claiming the same named server runtime.

Documentation refresh

• Replaced the long, technical root README with a concise project introduction,
  benefit summary, quick start, and documentation map.
• Added focused guides for getting started, the TUI, remote operation, safety,
  project guidance and Skills, MCP, configuration, architecture, and
  development.
• Added explicit token-strength guidance, remote-network warnings, trust
  boundaries, and current remote-mode limitations.

Protocol and safety

• Remote mode requires a shared token of at least 32 URL-safe characters; there
  is no unauthenticated mode.
• The server remains authoritative for its workspace, model, profile, and
  command policy.
• Remote command approval preserves the existing coding and sysadmin policies.
• The server accepts bounded request bodies and keeps runtime files private to
  the current user.

Remote quick start

Create the same private token file on both machines:

umask 077
mkdir -p ~/.config/zcoder
openssl rand -hex 16 > ~/.config/zcoder/remote.token

Start the server on the workspace machine:

./zcoder.zsh \
  --server "Workshop Mac" \
  --port 7337 \
  --token-file ~/.config/zcoder/remote.token \
  --model qwen3-coder \
  --workspace /path/to/project

Connect from the local machine:

./zcoder.zsh \
  --connect workshop-mac.local:7337 \
  --token-file ~/.config/zcoder/remote.token

Read the remote-agent guide for the complete setup.

Security note

The native Zsh TCP listener accepts connections on all interfaces. Remote mode
uses authenticated plain HTTP: the token prevents unauthenticated access but
does not encrypt traffic. Use it only on a trusted LAN protected by firewall
rules, or carry the connection through an SSH or VPN tunnel. Do not expose the
port directly to the internet.

Current limitations

The first remote release supports one active turn and one persistent session per
named server. Remote session browsing and reset, model switching, manual
compaction, management screens, and external consultant commands are not yet
exposed to the client.

Compatibility and verification

• Zsh 5.8 or newer
• Ollama with a tool-capable model
• 462 automated tests passing
• Native TCP smoke checks for authentication, remote turns, and duplicate-server
  locking
• Automated coverage for approval resumption and cancellation

For the full documentation, see the documentation index.