WebCodex v0.3.9

Highlights

• Streamlined first-run onboarding and npm package discovery, including webcodex share --auth query-token as the temporary-share fallback for MCP clients without Bearer-token UI.
• Expanded hosted and MCP connectivity with managed OAuth/connect paths and the local MCP gateway.
• Matured Workflow Session collaboration: canonical work_on_project, handoff/message observation, edit/withdraw/resolve flows, context ACK continuity, and Runtime Console collaboration surfaces.
• Improved Windows and Runner operations with lifecycle/bootstrap hardening, persistent execution, replacement readiness, SSH resource parity, and stronger readiness/status integrity.
• Hardened Server operations and release delivery with graceful Linux listener continuity, systemd rollback/lifecycle fixes, multi-architecture Server images, recoverable clone-free bootstrap, and disposable Server-image readiness.
• Improved long-running execution/recovery, ACP durability, bounded model-facing response economy, and release tooling.
• Added native Intel macOS (darwin-x64) release validation alongside Apple Silicon, Linux x64/arm64, and Windows x64/arm64.

Compatibility and upgrade notes

• runtime:read is observe-only for Workflow Sessions. Session post/resolve/complete/replace/withdraw/close operations require session:collaborate.
• Direct shared-key and normal pairing/full-interactive paths include session:collaborate. Existing PATs carrying only runtime:read must be reissued if they modify Session collaboration state.
• Existing OAuth clients do not automatically widen an omitted/legacy scope ceiling. Adding session:collaborate requires reauthorization; a real ceiling change revokes existing access/refresh tokens and outstanding authorization codes.
• webcodex share --auth query-token uses a temporary /mcp?token=... URL; the complete URL is a sensitive temporary credential. It is distinct from the deprecated Runner WebSocket query-token compatibility path; first-party Runners use Authorization: Bearer.
• Hosted Servers with an operator-provided shared key use webcodex connect. Fresh self-hosted Servers keep the bootstrap administrator token on the Server and enroll repository machines with a short-lived pairing code plus webcodex login.
• v0.3.8 remains the frozen previous-stable wire/rolling-compatibility fixture used by v0.3.9 validation.

Known client/platform boundaries

• Local one-command webcodex share remains a Linux/macOS path; Windows uses CLI + Runner against a remote Linux Server.
• ChatGPT Developer Mode, custom MCP Apps, and write/modify actions depend on plan/workspace/administrator policy; WebCodex cannot enable capabilities the client does not grant.

Release validation

The immutable v0.3.9 tag points to 9210e9b0342517ba7af15b2078ee708d49f96724.

Pre-tag exact-source release readiness passed on GitHub Actions run 32970465330, including the canonical release contract, full package-sharded Rust suites, frontend checks, WebSocket/polling zero-config E2E, coding-loop compare eval, native release-profile validation for all six published platforms, and disposable amd64/arm64 Server-image validation.

The authoritative post-tag release build passed on run 32975180128. All six native archives were built from the immutable tag with one shared build identity, Linux x64/arm64 passed the glibc 2.17 ABI/dependency gates, Windows artifacts passed native npm installer smoke, and one same-run assembled bundle was verified before publication.

WebCodex snapshot 2026-08-21 (085265f7)

Development snapshot for commit 085265f.

This is not an official WebCodex version release and is not published to npm. It is provided for users who need the latest hosted-connect OAuth feature without building from source.

Included artifacts:

• linux-x64: webcodex, webcodex-server, webcodex-runner
• win32-x64: webcodex.exe, webcodex-server.exe, webcodex-runner.exe
• SHA256SUMS

Both platform builds report commit 085265f and dirty=false.

WebCodex v0.3.8

WebCodex 0.3.8 is a V1 capability and reliability release focused on guarded cross-platform Computer Use, safer large-artifact transfer, durable Runner/Job recovery, and tighter model-facing bounds and authorization.

Highlights

• Windows and macOS Computer Use. The native Windows UI Automation and macOS Accessibility backends now share a semantic-first surface for exact window observation/activation, element discovery/state, press/focus, bounded text input, semantic scroll, and closed key input, with stale-handle fencing and outcome_unknown reconciliation instead of blind retries.
• Bounded application, display, pointer, and clipboard control. Windows and macOS add opaque-ID application discovery and launch, exact full-display discovery/snapshots, snapshot-generation-fenced pointer move/single-left-click, and bounded plain-Unicode clipboard read/write. The higher-risk operations remain separately capability- and scope-gated rather than being implied by ordinary Computer observation/control.
• Computer image delivery. Snapshot output is more tightly bounded, and MCP Computer snapshots can be surfaced through authenticated resource links instead of forcing large image payloads through the model-facing structured result.
• Streaming artifact data plane. Artifact upload/import/export paths now support bounded streaming-oriented transfer so large files do not require model-context-sized Base64 aggregation.
• Durable Job recovery. Detached Job ownership handoff survives Runner restart, including macOS parity, while process lifecycle and transport failure handling preserve explicit not-started/unknown semantics.
• Sessions, audit, and authorization. Hosted Workflow Session observability, authenticated caller attribution, unified bearer-scope enforcement, and the documented manual multi-window collaboration flow improve evidence and operator control without automatic transcript sharing.
• Tighter coding-tool bounds. Model-facing tool context is smaller, guarded text edits handle CRLF correctly, Git path mutations use structured argv, generated helper programs are isolated from configured shells, and sparse project-search output is reflected consistently in E2E/eval expectations.
• Release engineering hardening. Exact-source release-readiness, five-platform pre-tag native gates, guarded failed-tag recovery, durable release-build correlation, same-run bundle collection, and digest-based draft verification make publication recovery safer and more reproducible.

Compatibility and upgrade notes

There is no intentional breaking protocol change. New Runner capabilities are additive, default false when absent, and fail closed when an older peer cannot prove support.

Upgrade Server and Runner together before relying on the new Computer Use or detached-Job restart behavior. Full-display observation, pointer control, clipboard access, and application launch use explicit scopes/capabilities; existing clients do not receive those broader authorities automatically.

Known limitations

• Native desktop Computer Use is currently implemented for Windows and macOS; browser DOM/ARIA-native automation remains a separate future surface.
• Coordinate pointer control is intentionally narrow: move and one left click only, with no drag, wheel, right/double click, or generic global-coordinate API. The macOS pointer path currently requires an unrotated display.
• MCP App snapshot rendering can still be host-dependent; an intermittent blank/gray card has been observed even when the underlying capture succeeds.
• macOS x64 is not a published native artifact.
• The npm wrapper requires Node.js 18+ independently of native binary compatibility.

Validation

• Release source: 477c1f754e8b5c7d9f0e8b1c073487532a749101 at immutable annotated tag v0.3.8.
• Exact-source release-readiness run 32339887099 completed successfully, including the canonical release check, locked workspace suite, frontend checks, WebSocket and polling zero-config E2E, coding-loop comparison eval, and all five native pre-tag validation lanes.
• Coding-loop comparison eval: 6 passed / 0 failed.
• Authoritative release-build run 32343102712 completed successfully for Linux x64/ARM64, macOS ARM64, Windows x64/ARM64, plus the same-run assemble job.
• Both Linux targets passed the manylinux2014 ABI/dependency gates: x64 requires at most GLIBC 2.16 and ARM64 at most GLIBC 2.17, with only the reviewed dynamic dependencies.
• Windows release candidates passed the workflow's native package/install smoke.
• The staged npm package passed the retained-binary staging/smoke flow using the exact CI-produced candidate bytes.
• The retained candidate archives are published with SHA256SUMS; all five local retained hashes were rechecked immediately before draft upload.

WebCodex v0.3.7

WebCodex 0.3.7 is a V1 reliability and orchestration release focused on safer hosted project lifecycle, more durable Job behavior, bounded coding/validation tooling, and clearer MCP setup.

Highlights

• Hosted project disconnect. webcodex disconnect is the exact inverse of hosted webcodex connect: live project unregister uses Runner-side structured lifecycle fencing, preserves the source repository and .git, and fails closed on uncertain outcomes rather than blindly retrying or deleting local registration state.
• Managed Runner authorization hardening. Ordinary project unregister now enforces the managed Runner owner boundary before project visibility and active-Job fencing, with cross-owner regression coverage.
• Job reliability under backpressure. Promoted Job output capture is decoupled from transport backpressure while retained output remains bounded and terminal reconciliation stays durable.
• Bounded coding tools. Batch project-text search retries only transient dropped read-only Agent requests under the existing shared deadline/concurrency slot, while git_diff_hunks gains source-fenced bounded continuation.
• Focused Go validation. Structured Go validation supports a bounded list of project-relative package patterns while continuing to use machine-readable go test -json evidence and rejecting arbitrary flags, environment overrides, shell control, and caller-selected executables.
• Workflow and closeout evidence. The coding workflow separates bootstrap/session continuity from behavioral guidance and authority, while closeout evidence distinguishes historical failures from currently actionable unexpected failures without discarding raw history.
• Operator dogfood. The Windows Runner deployment helper is hardened around exact-process replacement, rollback, and interactive Scheduled Task behavior.
• MCP/OAuth setup. Grok Custom MCP Connector OAuth configuration is documented, including authorization-code flow, PKCE S256, client_secret_post, redirect URI registration, scopes, and common failure modes.

Compatibility and upgrade notes

There is no intentional breaking protocol change. New Runner/tool capabilities remain capability-fenced and fail closed when a peer does not support them.

webcodex disconnect requires a Server and Runner that implement structured project unregister. A newer CLI pointed at an older Server can fail closed with an unsupported/uncertain unregister result, so upgrade Server and Runner together before relying on the new lifecycle command.

Known limitations

• macOS x64 is not a published native artifact.
• The npm wrapper requires Node.js 18+ independently of native binary compatibility.
• webcodex disconnect manages hosted registrations created by webcodex connect; it is not a generic user-facing cleanup command for arbitrary pre-existing agent_registered projects.

Validation

• Release source: 44c1400542e9bda55ddffe89cf9dd45009f2ea88 at immutable annotated tag v0.3.7.
• Final source release gates, full workspace tests, and focused validation/handoff/coding-task lanes passed.
• WebSocket zero-config E2E: 111 passed / 0 failed.
• Polling zero-config E2E: 111 passed / 0 failed.
• Coding-loop comparison eval: 6 passed / 0 failed.
• Authoritative release-build run 31788623881 produced all five native targets successfully: Linux x64/ARM64, macOS ARM64, Windows x64/ARM64.
• Both Linux targets passed the manylinux2014 ABI gate; x64 requires at most GLIBC 2.16 and ARM64 at most GLIBC 2.17, with only the reviewed dynamic dependencies.
• Both native Windows targets passed the release workflow's npm artifact/install smoke.
• The staged npm package passed manifest, self-test, prepublish, pack, wrapper, and temporary-install checks using the exact CI-produced Linux x64 binaries; installed native files were byte-identical to the retained candidate.

WebCodex v0.3.6

WebCodex 0.3.6 adds bounded semantic code inspection and structured Go test evidence, expands the native release matrix to Windows ARM64, and rolls up the reliability and release-pipeline work completed since 0.3.5.

Highlights

• Bounded semantic code inspection. Adds typed call hierarchy / code_impact on the existing multi-language LSP bridge, with project-relative output, external/private location filtering, explicit capability negotiation, bounded depth/fanout/call-site/result budgets, and one shared operation deadline.
• Structured Go validation evidence. Go test recipes use go test -json ./... and derive bounded pass/fail/skip counts plus failed-test identities from machine-readable output.
• Native Windows ARM64 distribution. The main npm package now selects a native win32-arm64 artifact directly; x64 emulation is no longer the release path for ARM64 hosts.
• Five-target native release builds. Published artifacts cover Linux x64/ARM64, macOS ARM64, and Windows x64/ARM64. Both Linux artifacts are built in manylinux2014 userspace and enforce the glibc 2.17 / dynamic-dependency gates.
• CLI HTTP proxy controls. Adds an explicit credential-free HTTP proxy override and --no-system-proxy while preserving Runner proxy semantics.
• Runtime reliability. Fixes UTF-8 output-tail truncation panics, hardens persistent-shell/LSP/process lifecycle concurrency, and bounds queued Job start inputs.

Compatibility

There is no intentional breaking protocol change. New semantic-navigation and validation capabilities are negotiated explicitly and fail closed on older Runners.

Published native platforms:

• linux-x64
• linux-arm64
• darwin-arm64
• win32-x64
• win32-arm64

Known distribution limits: macOS x64 is not a published native artifact, and the npm installer wrapper requires Node.js 18 or newer.

Upgrade

Install or upgrade the main package normally:

npm install -g @yyjeqhc/webcodex@0.3.6

Upgrade Server/CLI/Runner together when possible so capability negotiation and runtime metadata stay aligned.

Release validation

The immutable v0.3.6 tag was built by the reviewed five-target release workflow from one source commit and one shared build timestamp. Native architecture/provenance checks, Windows npm-install smokes, Linux glibc/dynamic-dependency gates, release metadata validation, npm package tests, and an exact-binary npm install smoke all passed before publication.

v0.3.5

WebCodex 0.3.5

English | 简体中文

WebCodex 0.3.5 is a compatibility and maintenance release. It publishes the current post-0.3.4 mainline, lowers the native Linux x64 release baseline to glibc 2.17, hardens Runner proxy transport behavior, reduces Session persistence memory pressure, and includes Rust maintenance cleanup.

Highlights

• Linux x64 glibc 2.17 compatibility. The native linux-x64 artifact is built on the dedicated Special compatibility release builder with a glibc 2.17 userspace baseline. Release validation must reject binaries that require any GLIBC_* symbol version newer than 2.17. This addresses #20.
• Runner proxy transport hardening. Polling and WebSocket proxy handling on the Runner has additional compatibility and failure-path hardening from the post-0.3.4 mainline.
• Lower Session persistence memory pressure. Closed Session history and persistence paths reduce unnecessary in-memory duplication while preserving the durable Session contract.
• Rust maintenance cleanup. Dead-code and Clippy noise was reduced without changing the intended public runtime contract.
• Security documentation refresh. SECURITY.md, which GitHub renders as the repository Security Policy, now identifies 0.3.x as the supported security-fix line instead of the stale 0.2.x text.

Breaking changes and compatibility

There is no intentional breaking protocol change in 0.3.5.

Starting with this release, the native Linux x64 tarball targets glibc 2.17 or newer. This is an ELF compatibility guarantee for the published native linux-x64 binaries, not a blanket promise that every installation path works on every glibc 2.17 distribution. In particular, the npm wrapper still requires Node.js 18 or newer, and the available Node.js build must itself support the host.

The Linux arm64 artifact remains in the published matrix, but it does not yet carry the same glibc 2.17 compatibility guarantee. Its compatibility continues to depend on the native arm64 release host until that builder is migrated separately.

Upgrade notes

1. Upgrade webcodex, webcodex-server, and webcodex-runner together from the same immutable v0.3.5 revision.
2. Verify all installed binaries report 0.3.5, the same concrete commit, and dirty=false.
3. Linux x64 operators that were blocked by a glibc requirement newer than 2.17 should use the v0.3.5 native artifact or the npm wrapper on a host with a compatible Node.js 18+ runtime.
4. Linux arm64 users should not infer the x64 glibc 2.17 guarantee for arm64 in this release.

Binary packaging

The planned v0.3.5 release artifacts are:

• webcodex-v0.3.5-linux-x64.tar.gz
• webcodex-v0.3.5-linux-arm64.tar.gz
• webcodex-v0.3.5-darwin-arm64.tar.gz
• webcodex-v0.3.5-win32-x64.tar.gz

All artifacts must be built natively from the exact immutable v0.3.5 tag and carry the same release build timestamp. The Linux x64 build additionally uses the dedicated glibc 2.17 compatibility builder and an explicit readelf ABI gate before packaging.

Known limitations

• The glibc 2.17 release floor is currently guaranteed only for linux-x64; the linux-arm64 release builder will be addressed separately.
• Node.js compatibility is separate from native ELF compatibility. The npm installation path still requires Node.js 18 or newer.
• macOS x64, Windows ARM64, and other unpublished targets remain outside the release artifact matrix.

Release validation

This release-prep change does not add new runtime feature code. Validation should cover version consistency across Cargo/npm metadata, npm self-tests, Markdown links, clean release provenance, the existing source/CI gates, and the new Linux x64 GLIBC_* <= 2.17 artifact check.

Next steps

Migrate the Linux arm64 release builder to an equivalent controlled compatibility baseline before making the same glibc floor claim for that artifact.

v0.3.4

WebCodex 0.3.4

English | 简体中文

WebCodex 0.3.4 is an execution reliability and ergonomics release. It makes
model-facing command execution safer to retry, less dependent on shell quoting,
able to continue durably without rerunning work, easier to observe in batches,
more responsive over polling, and more predictable on Windows.

Highlights

• Truthful execution lifecycle and retry safety. Structured execution state
  now distinguishes work that definitely did not start, work that may have
  started with an unknown outcome, timed-out work, and completed work. Models no
  longer need to infer retry safety from prose error strings.
• Structured process and script execution. run_process carries executable
  and argv as typed data, while run_script carries bounded script content,
  script argv, and stdin separately. Neither path reconstructs shell text, and
  both fail closed instead of silently falling back to shell execution when the
  required Runner capability is unavailable.
• Same-execution sync-to-Job handoff. A structured process or script that
  outlives the synchronous grace continues as the same durable Job with the same
  execution identity and timeout budget. Handoff does not cancel, restart, or
  replay the child process.
• Batch Job observation. observe_jobs can inspect up to eight existing Jobs
  in one bounded call, using one shared wall-clock wait and returning fresh
  sibling observations together after a meaningful change.
• More responsive polling and practical Job concurrency. Polling can keep
  making progress while an ordinary request is still running, without replaying
  execution. Runner Job execution now defaults to four concurrent Jobs, supports
  an effective max_concurrent_jobs range of 1 through 64, preserves FIFO
  promotion of the original queued Job, and exposes bounded running/queued/limit
  observability.
• Deterministic Windows output normalization. Local Windows process output is
  presented as bounded valid UTF-8 across UTF-8, BOM-declared UTF-16, and the
  active OEM code page. Streaming preserves split UTF-8 scalars, UTF-16 units,
  and OEM DBCS characters across chunk boundaries; PowerShell 5.1 script
  param(...) semantics and exactly-once timeout/stop behavior remain intact.

Breaking changes and compatibility

There is no intentional breaking protocol change in 0.3.4. The new execution
capabilities and observability fields are additive and fail closed when an older
Runner does not advertise them.

Operators should note one intentional runtime default change: Runner Job
execution concurrency is now four. Set max_concurrent_jobs = 1 when strict
serialization is required. The setting remains restart-required, and values are
normalized to the effective range 1 through 64. Polling dispatch capacity is a
separate fixed bound of two and is not derived from Job concurrency.

Clients that cache MCP/OpenAPI tool schemas should refresh them after upgrading
because the structured execution and Job observation surface changed.

Structured execution details

run_process is for native executable/argv execution and never reconstructs a
shell command. On Windows, native .exe, .com, and extensionless PE images are
accepted; .cmd and .bat remain shell/script concerns and are rejected before
spawn on this typed path.

run_script currently supports explicit sh, bash, and powershell
interpreters through Runner-owned temporary script files. Named SSH Session
resources do not gain typed process/script transfer in this release; use
run_shell when shell or remote SSH shell semantics are intentionally required.

If a capable Runner cannot finish a structured execution during the bounded
synchronous grace, WebCodex exposes the already-running execution as a durable
Job. The public timeout remains one total budget rather than being reset at
handoff.

Job observation and concurrency

observe_jobs accepts 1 through 8 existing Job ids and optionally their prior
observation tokens. A requested wait is one batch deadline, not a per-Job wait.
The call is observation-only: it does not launch, retry, stop, schedule, or
subscribe to Jobs.

Runner Job execution uses the existing bounded inventory and queue. The default
concurrency is four; eligible queued Jobs are promoted FIFO with their original
job_id and request, exactly once. list_agents and runtime_status expose the
effective static limit and authorization-filtered running/queued counts without
deriving an available_slots or saturated claim.

Windows execution behavior

For local model-facing process output, Windows decoding follows a deterministic
order: UTF-8 BOM, wholly valid UTF-8, BOM-declared UTF-16LE/BE, then the active
Windows OEM code page. CRLF is presented as LF while lone CR is preserved, and
output is bounded again after transcoding so encoding expansion cannot bypass the
model-facing byte cap.

The 0.3.4 acceptance cycle exercised native Windows/MSVC execution including an
OEM CP936 environment, UTF-8 and UTF-16 output, PowerShell 5.1, split UTF-8/OEM
streaming, timeout/stop exactly-once behavior, and Runner service-context polling.

Remote SSH streams retain their existing remote UTF-8/lossy contract, and
persistent-shell framing is unchanged. Windows x64 remains a supported CLI +
Runner platform connecting to a remote Linux Server; long-running local Windows
Server operation and productized Windows SCM installation remain outside the
supported deployment model.

Upgrade notes

1. Upgrade webcodex, webcodex-server, and webcodex-runner together from the
   same immutable v0.3.4 revision.
2. Verify all installed binaries report 0.3.4, the same concrete commit, and
   dirty=false.
3. Refresh cached MCP/OpenAPI schemas so clients discover run_process,
   run_script, observe_jobs, and the current Job/runtime output fields.
4. If you set max_concurrent_jobs, restart the Runner after changing it; the
   setting is intentionally not hot-reloadable.
5. On Windows, continue using the CLI/Runner path against a remote Linux Server;
   the packaged webcodex-server.exe does not make long-running Windows Server
   runtime a supported deployment.

Binary packaging

The planned v0.3.4 release artifacts are:

• webcodex-v0.3.4-linux-x64.tar.gz
• webcodex-v0.3.4-linux-arm64.tar.gz
• webcodex-v0.3.4-darwin-arm64.tar.gz
• webcodex-v0.3.4-win32-x64.tar.gz

Each publishable artifact must be built natively from the exact immutable
v0.3.4 tag and contain webcodex, webcodex-server, and webcodex-runner
(.exe on Windows). Real SHA-256 checksums are generated from the final native
archives after tagging; they are not committed as placeholder release metadata.

Known limitations

• observe_jobs batches observation only; it does not add batch Job launch or a
  new scheduler.
• Structured process/script execution over named SSH Session resources is not
  part of this release; intentional SSH shell work continues through run_shell.
• Remote SSH stream decoding and persistent-shell framing are unchanged by the
  Windows local-output normalization work.
• Windows supports client/Runner operation, not the long-running local Server,
  productized SCM installation, Windows ARM64, or UNC project roots.
• macOS x64 and other unpublished targets remain outside the release artifact
  matrix.

Release validation

The execution A–F cycle completed cross-platform acceptance on Linux and real
Windows/MSVC, including MSI Runner service-context execution. The final release
candidate still follows the repository release gates: formatting, workspace
compilation and tests, focused runtime/schema coverage, native builds on all four
release hosts, npm self-tests and staged install smoke, provenance/build-identity
checks, Markdown link validation, checksum verification, and clean-worktree
review.

Next steps

The execution A–F cycle is complete. Further execution work in this cycle is
maintenance/stabilization unless a new concrete reliability or product need is
demonstrated; 0.3.4 does not begin a new execution feature phase.

WebCodex v0.3.3

WebCodex 0.3.3

English | 简体中文

WebCodex 0.3.3 adds native Windows x64 client/Runner support and the MCP
2026-07-28 stateless tools core, while also making one-machine temporary sharing
and ChatGPT OAuth discovery easier to use.

Highlights

• Native Windows x64 client + Runner. webcodex and webcodex-runner now
  support Windows-native repository work, command execution, process-tree
  cleanup, path handling, Git operations, validation jobs, and LSP navigation.
  The supported Windows deployment model connects the Windows Runner to a remote
  Linux WebCodex Server.
• MCP 2026-07-28 stateless tools core. Modern MCP clients can negotiate with
  server/discover and call tools/list / tools/call without the legacy
  initialize/session lifecycle. The existing MCP 2025-06-18 path remains for
  compatible legacy clients.
• Temporary local sharing. webcodex share can start an isolated local
  Server + Runner, create a temporary Project Connector credential, and expose
  /mcp through a Cloudflare Quick Tunnel for short-lived use without requiring
  a Cloudflare account.
• ChatGPT OAuth MCP discovery compatibility. OAuth discovery now handles the
  metadata flow expected by ChatGPT MCP clients while keeping WebCodex's
  existing authorization boundaries.
• Stronger release provenance. Native Windows packaging verifies the exact
  tagged commit, clean build identity, shared binary metadata, and archive
  contents before an artifact can be treated as publishable.

Windows support scope

Windows x64 is supported for the CLI and Runner. It is intended for local
Windows repositories connecting to a remote Linux Server.

Not supported on Windows in 0.3.3: a long-running local WebCodex Server,
webcodex share, webcodex agent install, persistent shells, SSH resources,
config hot reload, AppContainer sandboxing, ARM64, or UNC project roots.
webcodex-server.exe remains in the Windows archive only to preserve the common
three-binary npm artifact contract.

After a Windows machine restart, resume a hosted Runner explicitly with the same
webcodex connect ... command or webcodex agent start --profile <name>.
Automatic startup at login/reboot is not part of this release.

MCP compatibility

The 2026-07-28 path is stateless at the transport layer: each request carries its
protocol metadata and standard MCP headers, and WebCodex does not mint or depend
on Mcp-Session-Id for that path. Durable WebCodex work still uses explicit
application handles such as task and Workflow Session identifiers.

MCP 2025-06-18 initialization/session behavior remains available for existing
clients. Clients that cache tool schemas should refresh them after upgrading.

Upgrade notes

1. Upgrade webcodex, webcodex-server, and webcodex-runner together from the
   same immutable v0.3.3 revision.
2. Verify that all installed binaries report 0.3.3, the same concrete commit,
   and dirty=false.
3. Refresh cached MCP schemas so clients can discover the 2026-07-28 transport
   behavior and current tool surface.
4. On Windows, use the CLI/Runner path against a remote Linux Server; do not
   treat the packaged webcodex-server.exe as a supported Windows service.

Binary packaging

The v0.3.3 release artifacts are:

• webcodex-v0.3.3-linux-x64.tar.gz
• webcodex-v0.3.3-linux-arm64.tar.gz
• webcodex-v0.3.3-darwin-arm64.tar.gz
• webcodex-v0.3.3-win32-x64.tar.gz

Each artifact was built natively from the exact immutable v0.3.3 tag and
contains the three runtime binaries (.exe on Windows). The SHA-256 values of
the exact upload candidates are:

• linux-x64: 9b41648a2ca22a2919a47fd52db8a2e9c88b605b8afc9f378929922d3227ffa4
• linux-arm64: 305eeca72321cca19632cecf9780dcb60a6719291e9ca76bb48a8b00924fb88c
• darwin-arm64: bd2ad416d21115248a0473afb186048151de7b407bbfd8eff6f1bb60d09429eb
• win32-x64: de44975c7abe5e3947bb486b2fe9172840dcbe3faec07633d8512b72efb790c2

Known limitations

• macOS x64, Windows ARM64, and other targets are not published by this release.
• Windows supports client/Runner operation, not the long-running local Server or
  OS service-install path.
• The Docker image remains server-only; repository machines still need a Runner.
• Connected clients can modify files and execute commands within configured
  boundaries. Use version control, recoverable backups, and appropriately
  scoped OS users.

Release validation

The release candidate must pass formatting, workspace compilation and tests,
focused MCP/runtime coverage, native Windows validation, npm self-tests,
artifact-to-npm installation smoke, release binary identity/provenance checks,
Markdown local-link validation, and clean-worktree review. The final publishable
artifacts must be rebuilt from the immutable tag on their native release hosts.

WebCodex 0.3.2

WebCodex 0.3.2

English | 简体中文

WebCodex 0.3.2 makes the product easier to install and operate while simplifying
the coding tool surface and tightening mixed-version Runner behavior.

Highlights

• Server-only Docker Compose deployment. The repository now includes a
  hardened Dockerfile, Compose file, environment template, and bootstrap script
  for running the coordination Server without placing repositories or Runner
  toolchains in the container.
• Safer non-root Runner services. Runner lifecycle commands support explicit
  user and system service scopes. Non-root users can install a persistent
  systemctl --user service without sudo; system services require an explicit
  Runner account, and root execution requires an explicit opt-in.
• Clearer credential guidance. CLI diagnostics and documentation distinguish
  user/runtime credentials from Agent transport tokens without weakening the
  existing Server authorization boundary.
• Capability-gated project registration. A Server can resolve or register a
  project from an absolute Runner path only when the connected Runner advertises
  the required capability. New Servers reject older Runners before sending an
  unsupported internal request.
• Smaller editing surface. Retired single-purpose edit tools and compatibility
  branches have been removed. The supported write path is centered on whole-file
  writes, transactional text edits, and checked patches. Unknown or retired
  file_* requests now fail before provider or shell fallback.
• Shorter public documentation. The README now focuses on the product,
  installation, hosted connection, Docker self-hosting, and the everyday tasks
  an online AI assistant can perform on connected machines.

Quick start

npm install -g @yyjeqhc/webcodex
cd /path/to/your/repository
webcodex connect https://sg4.yyjeqhc.cn

Add the MCP URL and generated key printed by connect to ChatGPT or Claude, then
ask it to inspect files, edit code, run tests, or work with Git.

Docker self-hosting

The included image is intentionally server-only: it contains
webcodex-server and the administrative webcodex CLI, but not
webcodex-runner, repositories, or language toolchains.

git clone --branch v0.3.2 --depth 1 \
  https://github.com/yyjeqhc/webcodex.git
cd webcodex
./deploy/docker/bootstrap.sh https://webcodex.example.com

The current Compose path builds from the tagged source checkout. Publishing the
same server-only image to GHCR or Docker Hub is a separate release operation and
is not required for a valid source or binary release.

Breaking changes

• The seven retired single-purpose edit tools are no longer exposed. Use
  transactional text edits, checked patches, or whole-file writes instead.
• MCP and GPT Actions clients that cache schemas must refresh them before using
  the 0.3.2 tool surface.
• Old Servers that send retired or unknown file_* request kinds to a 0.3.2
  Runner receive a deterministic unsupported-request failure instead of shell
  or provider fallback.
• Mixed Server and Runner versions are not recommended for this upgrade.

Upgrade notes

1. Upgrade webcodex, webcodex-server, and webcodex-runner together from
   the same v0.3.2 tagged revision.
2. Restart the Server and each Runner, then verify that all binaries report
   0.3.2, the same clean build revision, and dirty=false.
3. Refresh cached MCP or GPT Actions schemas because the legacy edit tool
   surface has been removed.
4. Existing hosted profiles and managed credentials remain separate; an Agent
   token still cannot be used for project or runtime APIs.
5. Non-root Runner installations should prefer --scope user. Review existing
   system services before reinstalling them under the new scope model.

Binary packaging

The planned binary artifacts are:

• webcodex-v0.3.2-linux-x64.tar.gz
• webcodex-v0.3.2-linux-arm64.tar.gz
• webcodex-v0.3.2-darwin-arm64.tar.gz

SHA-256 checksums of the exact uploaded release assets:

ee6fd40d26524dd3d4ad76b2fdb31a626d0321703b55414ff66b7962b4ec3aaa  webcodex-v0.3.2-linux-x64.tar.gz
bb582960d6ab0b6001514997e4fa23adcbabf355c878abd6c790ac83e4c13aab  webcodex-v0.3.2-linux-arm64.tar.gz
56bfc43cb1dce0ede9810f81a4eb0a25d5e991fb729db6154b16cca35cfb8533  webcodex-v0.3.2-darwin-arm64.tar.gz

Each artifact must contain webcodex, webcodex-server, and
webcodex-runner built from the exact immutable v0.3.2 tag. The npm package
must not be published until the exact uploaded bytes have been recorded in the
release manifest with their real SHA-256 checksums.

Known limitations

• The npm package does not currently cover Windows, macOS x64, or other targets.
• The Docker container runs only the coordination Server; every repository
  machine still needs a Runner.
• A detached hosted Runner survives terminal closure but must be restarted after
  a machine reboot unless it is installed as an OS service.
• Connected clients can modify files and execute commands within configured
  boundaries. Use version control, recoverable backups, and appropriately
  scoped OS users.

Validation before release

The final tagged candidate should pass formatting, workspace compilation and
tests, hosted-connect and Runner lifecycle E2E coverage, npm package smoke,
release-binary identity checks, Docker build/health smoke, Markdown local-link
validation, and clean-worktree review.

Next steps

After upgrading, refresh the client schema, verify Server and Runner build
identities, and run one read-only project task before resuming write access.

Acknowledgements

Thanks to the LINUX DO community for its welcoming space
for technical discussion and support for open-source sharing.

WebCodex 0.3.1

WebCodex 0.3.1

English | 简体中文

WebCodex 0.3.1 focuses on making the official hosted path practical for a new user while tightening Runner transport and job-recovery behavior.

Highlights

• One-command hosted onboarding. After installing the npm package, a user can enter a repository and run webcodex connect https://sg4.yyjeqhc.cn. The CLI generates a strong shared key, writes a project-bounded profile, starts one detached Runner, and verifies that the hosted Server can see both the Runner and project.
• Safer shared-key operation. Hosted Runner registrations are bounded, generated keys are disclosed only once, logs rotate with bounded retention, and shared-key expiry no longer rewrites already-lost jobs into a misleading terminal state.
• Unified transport supervision. WebSocket and QUIC use one reconnect, shutdown, fallback, and error-classification lifecycle. Auto mode can fall back to WebSocket, while strict QUIC treats certificate failures as fatal and transient network failures as retryable.
• macOS persistent-shell compatibility. Darwin now creates the shell control pipe with pipe and immediately applies FD_CLOEXEC, while Linux/Android retain atomic pipe2(O_CLOEXEC) behavior.
• More reliable job recovery. Reconciliation preserves job identity and log cursors across Server restarts, distinguishes recoverable and legacy Runner disconnects, and keeps hidden handoff/cleanup jobs outside public history retention.
• Lower-friction model workflows. Startup briefs, continuation feedback, bounded batch file reads/searches, asynchronous validation jobs, SSH-backed Session contexts, and managed temporary projects reduce round trips without widening project boundaries.
• Bilingual release documentation. The repository and npm package now carry English and Simplified Chinese onboarding, platform, recovery, disclaimer, and LINUX DO acknowledgement sections.

Hosted Quick Start

Release artifacts are available for Linux x64, Linux arm64, and macOS arm64:

npm install -g @yyjeqhc/webcodex
cd /path/to/your/repository
webcodex connect https://sg4.yyjeqhc.cn

Copy the generated MCP key immediately. It is stored in the owner-only profile but is not printed again by status or log commands. A detached hosted Runner survives terminal closure but not a machine reboot; after reboot, rerun connect or use webcodex agent start --profile <profile>.

Upgrade Notes

1. Upgrade webcodex, webcodex-server, and webcodex-runner together from the same v0.3.1 artifact/build revision.
2. Restart the Server and each Runner, then verify that all binaries report 0.3.1, the same commit, and dirty=false.
3. Refresh cached MCP or GPT Actions schemas when a client retains an older tool list.
4. Existing managed credentials and hosted profiles remain separate. A wc_* managed credential never falls back to shared-key authentication.

No intentional public CLI command or canonical MCP operation is removed in this patch release.

Packaging

The npm package is a thin installer/wrapper. The v0.3.1 manifest declares:

• webcodex-v0.3.1-linux-x64.tar.gz
• webcodex-v0.3.1-linux-arm64.tar.gz
• webcodex-v0.3.1-darwin-arm64.tar.gz

Each artifact contains webcodex, webcodex-server, and webcodex-runner from one clean tagged revision. The release-preparation tag intentionally keeps checksum placeholders. npm must not be published until all three immutable artifacts are uploaded and the exact SHA-256 values are committed in a reported post-tag manifest commit without moving v0.3.1.

Known Limitations

• A hosted shared key is a capability credential. Anyone who possesses it can use the permissions of the associated project-bounded Runner profile.
• The detached Runner is not an OS startup service and must be restarted after a machine reboot.
• macOS x64 and Windows artifacts are not part of the v0.3.1 npm coverage.
• The browser console is a review and operations surface, not a full IDE.
• Production safety still depends on HTTPS, scoped credentials, OS-user isolation, backups, and operator review.

Disclaimer

WebCodex is provided only for research and learning. It can read and modify files and execute commands inside configured project boundaries. Use it only with version control and recoverable backups. The author is not responsible for filesystem damage, data loss, or other consequences arising from use of the software.

Validation

The release candidate is required to pass formatting, workspace compilation/tests, hosted-connect and job-recovery real-process E2E coverage, npm installer/package smoke, release-binary identity checks, Markdown local-link validation, and clean-worktree/hygiene review before the tag is created.

Acknowledgements

Thanks to the LINUX DO community for its welcoming space for technical discussion and support for open-source sharing.

Release Artifacts

This release provides native artifacts for Linux x64, Linux arm64, and macOS arm64. Windows and macOS x64 are not included in v0.3.1.

c3b31bb216639a39091b99f021f361a10ec59488a2c11bde471c9fb46e20f0b7  webcodex-v0.3.1-linux-x64.tar.gz
e630f6ac5b02243a866b80e0f97689a35a556ea53b37f5253ccee99394c61e6a  webcodex-v0.3.1-linux-arm64.tar.gz
a8882bf999771ccdc9339f40dc4ec0725f634b632410fa2f7394e0ce32c2a513  webcodex-v0.3.1-darwin-arm64.tar.gz