v2.4.0

Added

• cs compile-set <zip|URL> and cs compile-set --skip answer the editor's
  one question about a running player: should code submitted to it be compiled
  against the build it is actually running? By default, player builds export
  CSharpConsoleCompileSet.zip beside their output; Project Settings > C# Console
  can disable export or override the path. Hand that file — a path or an
  http(s) URL — to cs compile-set, or decide with --skip that this build is
  compiled for without alignment. Like cs exec --mode runtime, --ip/--port
  name the player and the 15500-15509 range is probed when no --port is given;
  the registration itself goes to the editor, which is what keeps the decision.

  The decision is stored per build GUID under the editor project's
  Library/CSharpConsole/, so it is made once per build and shared by every
  agent and client. It survives an editor restart and can be overwritten at any
  time by registering or skipping again.

  A missing zip fails as a validation error (exit 1); a download failure, a zip
  that cannot be read, and no player found to name fail as system errors (exit
  3); a zip the editor itself rejects — wrong build, no build GUID inside, the
  player unreachable from the editor — as a validation error (exit 1). An
  editor whose package predates the endpoint answers 404, and the CLI says to
  update the package.

Changed

• Hierarchy responses now preserve deep trees and report nodeCount, truncated,
  and truncationReasons (requested_depth, node_limit, or depth_limit).
  Responses are bounded to 5000 nodes and depth 128 for JSON client safety. Component type names
  are namespace-qualified so inspection output can be reused as typeName.
  The pinned contract fixture is updated to match package 2.4.0.

• Runtime debugging guidance permits supporting file evidence when execution is
  unavailable or build contents need verification. File inspection does not
  authorize registering a compile set or bypassing the alignment gate.

• Text cs health output now identifies the answering process and its build.
  Failed runtime submissions include guidance for possible stripping, and an
  exact command lookup in the wrong view names the view to query.

• Developer tests, routing evaluations, and fixtures now live under dev/ so
  skill installation copies only the files needed at runtime.

• cs exec --mode runtime against a player that reports its build is refused
  until that build has a decision, with exit code 1 and a summary beginning
  [REPL ALIGNMENT REQUIRED]. The CLI appends the cs compile-set command to
  run — with this call's own --ip/--port — to both the text summary and the
  --json envelope. Ask the user for the zip or for an explicit decision to
  skip; skipping is not the agent's call to make. Players must report a valid
  build GUID; older players must be rebuilt with the matching package version.

• cs health --mode runtime reports buildGuid, the build the player came
  from — the same value cs compile-set registers against. The editor never has
  one, so the compact --json form omits the field when it is empty rather than
  showing a blank.

• A package on another major.minor line is now refused, not warned about.
  The CLI and the package are released together, so a mismatched pair can
  disagree about the wire without either side saying so — and the warning that
  said as much only ever appeared in cs setup, never on the path that actually
  drives Unity. Every command that reaches Unity now fails with
  Error: unity-cli X.Y.Z does not match package A.B.C (exit 1). cs setup and
  cs status stay usable, because they are how the mismatch is fixed and seen,
  and commands that never reach Unity — cs doctor, cs wait-ready, offline
  listings — are unaffected. The patch digit is not part of the line, and a
  version that cannot be read is never treated as a mismatch.

• A result that merely mentions an exception is no longer a runtime error.
  The service used to classify any response text containing exception as
  runtime_error (exit 2), so an evaluation that returned such a word failed a
  command that had in fact succeeded. Classification now matches only the
  failure text the service writes itself, and those results exit 0. This is
  included in package 2.4.0.

v2.3.2

Changed

• exec-code.md now documents two Roslyn REPL statement-form pitfalls that
  make otherwise-correct C# fail to compile in a raw cs exec fallback.
  Expression auto-return applies only to the final expression and only when it
  has no trailing ; — a trailing semicolon (or the same expression placed
  mid-script) makes it a statement, and a member access, comparison, or ternary
  in statement position is CS0201; drop the ; or write return <expr>;.
  Separately, top-level code is not inside a class instance, so members inherited
  from object are out of unqualified scope — call object.Equals(a, b), not a
  bare Equals(a, b) (a bare call is CS0103). Both were verified against the
  live REPL.

v2.3.1

Added

• cs logs [PATH] follows a log file on whichever process is being
  addressed, printing new bytes as they are written. Without a path it follows
  the target's own consoleLogPath; on Android and iOS, which write no log file
  of their own, it says so and asks for the path the project logs to. Rotation
  is detected — when the file becomes shorter than the read position, it
  restarts from the beginning of the new file rather than silently skipping it.
  --since-start reads from the beginning, --interval sets the poll period,
  and --wait bounds a foreground run so it cannot hang an agent that has no
  Ctrl+C.

  It is built on the same download route as cs pull, so it needs no editor:
  watching a player on another machine is the case it exists for.

• cs logs --background collects into a file and prints its path, leaving
  the terminal free. Other commands run against the same target meanwhile —
  measured at the same failure rate as with no collection running. The detached
  follower keeps going until the target it is watching goes away, so a player
  that runs for hours is covered for all of them; a single dropped connection
  is not mistaken for that, since the service drops one occasionally under
  load. --stop ends it early, and starting it twice for the same target hands
  back the collection already running rather than starting a rival reader.

Fixed

• health was resetting one call in five. Requires package 2.3.1. The
  service wrote the health response without ever reading the request body the
  client had sent, and Windows tears down a response closed over an unread body
  with RST rather than FIN — so the answer was written and the caller saw a
  dropped connection instead. Measured at 8 failures in 40 calls against a
  player and 2 in 40 against an editor; 0 in 40 after the package drains the
  body first. cs doctor and cs wait-ready probe through health, so both
  carried the same odds of failing at random. Every other route reads its body
  and was never affected.

• The runtime port probe caused the failures it was blamed for. It opened a
  TCP connection to each candidate and closed it without sending a request,
  which left the service cleaning up a half-started connection and reset the
  request that followed — 4 failures in 30 calls, against none when the range
  was not probed. Each candidate is now asked a real health question, which
  also confirms that what answers is this service rather than an unrelated
  process holding the port. The usual port is tried alone before fanning out,
  because the service accepts and dispatches one request at a time and a
  ten-way fan-out costs it more than it costs the client. Probing now measures
  the same as not probing. Finding no player takes about a second longer.

v2.3.0

Fixed

• --mode runtime now addresses the player. It only ever affected cs exec;
  health and every canonical command went to the editor regardless. So
  cs health --mode runtime called a dead player healthy, and
  cs command session/list --mode runtime listed the editor's REPL sessions
  rather than the ones cs exec --mode runtime had created in the player.
  Commands whose contract does not require the editor now reach the player.
  command/list and command/registry.snapshot deliberately stay with the
  editor, which owns registry authority; answering them from a player would
  overwrite the project's cached contracts with its shorter list.
• When no player answers on 15500-15509, commands that need one exit 3 and say
  so instead of falling back to the editor.
• cs batch --mode runtime sent the whole batch to the editor while cs command
  reached the player, so the same command id answered from a different process
  depending on how it was invoked — and a batch of mutations applied to the
  editor. A batch is one roundtrip, so command/list and
  command/registry.snapshot cannot be split out of it and are refused there
  instead; request them separately without --mode runtime.

Added

• cs pull retrieves a file from whichever process is being addressed. A
  relative path resolves against the target's persistentDataPath — the form to
  use against another machine, since Android and iOS give a user no absolute
  path to hold. An absolute path names a file on the target and is used as
  given. Every pull reports which rule applied. Large files are fetched as
  successive ranges.
• references/player.md covers debugging a running player: what it answers,
  why a device reports no consoleLogPath, and how to record a profiler capture
  on a device and open it at home.
• runtime/info routing: the device, build, and well-known paths of whichever
  process replies.

Changed

• The runtime port probe runs its ten candidates concurrently at 1s each rather
  than one after another at 0.3s. Hosts that drop packets to closed ports made
  the sequential form cost the full timeout per port, and the longer per-port
  budget suits a player on another machine.
• The package-owned registry grows to 62 (56 authoring + 6 control).

v2.2.0

Added

• cs test — run Unity Test Framework tests (EditMode or PlayMode) through
  the new editor/test.run/editor/test.status package commands, poll until
  completion across play-mode transitions and domain reloads, and report
  structured pass/fail results (exit 0 pass, 3 failures, 4 outcome unknown).
  Requires com.unity.test-framework in the consuming project; without it the
  commands stay discoverable and return an explanatory error.
• ScriptableObject authoring — scriptableobject/create, scriptableobject/get,
  and scriptableobject/modify package commands in the assets domain for
  creating SO assets by type and reading/writing their serialized fields.

Changed

• The authoring surface grows to 56 commands (61 package-owned built-ins with
  the 5 control-plane contracts); documented counts now match the registry.
• READMEs state the trusted-LAN service model explicitly: the Unity-side
  service binds all interfaces without authentication by design and must not
  be exposed to untrusted networks.

v2.1.0

Added

• cs doctor — read-only reliability diagnosis with structured findings
  (project/package/version offline checks plus live service health), working
  before the Unity package is installed.
• cs wait-ready — poll until the editor service is genuinely ready
  (phase, compile/update flags, and the 2.1 main-thread heartbeat), with
  --expect-operation/--min-generation to bind the wait to one refresh
  operation and reject stale state from earlier generations.
• Play-mode compile deferral detection — when a waited refresh is deferred
  by the editor's Script Changes While Playing preference
  (recompile_after_finished), cs refresh --wait and cs wait-ready fail
  fast with editor.play_mode_deferring_compile instead of burning the
  timeout, and instruct the agent to ask the user before exiting play mode.

Changed

• cs refresh --wait readiness now binds to the triggered operation — the
  wait tracks the returned operation id and generation rather than the first
  ready phase mirror, so a service-restart blip can no longer report ready
  while the requested compile is still pending.
• references/refresh.md no longer recommends --exit-playmode by
  default — plain cs refresh --wait is the first choice; exiting play mode
  requires the user's approval because it discards runtime state.
• CLI version moves to 2.1.0 to stay on the same compatibility line as the
  Unity package's 2.1.0 health-field additions.

v2.0.8

Removed

• cs complete and the /completion bridge — unity-cli no longer exposes the
  interactive completion endpoint. Agent automation submits complete C# and had no
  internal consumer for completion candidates; the Unity package may continue to
  provide /completion for its own interactive clients.

Changed

• Cross-agent repository guidance now has one source of truth — AGENTS.md
  contains the shared CLI, architecture, test, setup-safety, and release rules;
  CLAUDE.md imports it with @AGENTS.md instead of maintaining a drifting copy.
• REPL behavior documentation synced with the Unity package —
  references/exec-code.md now explains that only successfully compiled using
  directives persist, that ambiguous internal compatibility types can make one
  submission fall back to standard C# accessibility, and how to respond to
  [REPL NOTICE] / [REPL ACTION REQUIRED]. Those upstream behavior changes did
  not alter endpoint paths or request/response contracts.

v2.0.7

Fixed

• Cross-call REPL context is now available on demand — --session <id> is
  forwarded through cs.py and core_bridge.py to the C# Console request UUID, so
  dependent cs exec calls can intentionally share variables, usings, types, and
  helpers. Omitting the option keeps the previous fresh-session default; unrelated
  agents/tasks use different ids, and domain reload still clears all session state.
  The skill now tells agents to opt in only for genuinely dependent calls instead of
  claiming state is either always shared or never shareable.
• cs status text mode now exits like the JSON branch — 0 only when the live
  service is healthy; no project / package missing / service unreachable all exit 1
  (previously the text branch returned 0 for everything but a missing project),
  matching the new "text mode: exit code carries success" convention. When the
  service is down, text mode now also prints the installed package version read
  from disk (version: X.Y.Z (package on disk)) instead of omitting the version
  line entirely.

Changed

• --json is no longer blanket-required (docs only, CLI unchanged) — the skill now
  asks for --json only on the four commands whose payload is emitted solely as
  structured JSON (command, list-commands, batch, complete). All other
  subcommands print an equivalent, cheaper text form and run without it; exec adds
  --json only when the structured envelope is needed. (cs setup never had a JSON
  branch — its documented --json was silently ignored.)
• C# code goes through --file, never JSON-wrapped — SKILL.md and
  references/exec-code.md now make a raw .cs file the only documented way to pass
  code to cs exec; the --input '{"code": …}' form (every quote/backslash/newline
  JSON-escaped) is demoted to a stdin-piping edge case. Scratch .cs / req.json
  files now have a mandatory location: the absolute path
  <project-root>/Temp/CSharpConsole/AgentScratch/ — inside Unity's own Temp/
  (never imported, auto-cleaned on editor close, write-sandbox-friendly for
  workspace-bound agents, and colocated with the service's existing
  Temp/CSharpConsole/ state). Semantic file names, overwritten per task; one-shot
  suffix only under known same-project concurrency. Never under Assets/ (a typical
  REPL snippet fails project compilation there — blocking refresh workflows and,
  after an editor restart, potentially preventing the service from starting), and
  never delete Temp/CSharpConsole/ itself. Decided in an adversarial CC↔Codex
  review (local audit transcript:
  cc-codex-discussion-history/20260722-213810-scratch-file-conventions.md, kept
  untracked by repo policy), which replaced the earlier
  <user-temp>/csharpconsole/<session>/ draft: a user-temp root is not guaranteed
  writable under workspace-bound agent sandboxes, and the session token was pure
  bookkeeping.
• First-time setup asks which source shape (references/setup.md) — before writing
  the manifest the agent now offers an explicit choice: pinned git URL (default,
  team-friendly) vs. cloning the package to a user-chosen local path and installing via
  --source file:<dir> (agent performs the clone; caveat documented that absolute
  file: paths in the committed manifest are machine-specific).

v2.0.3

Fixed

• core_bridge retry survives the urllib core — the domain-reload retry wrapper
  (_make_post_with_retry) caught only OSError, which the old requests-based core
  satisfied (its exceptions subclass OSError) but the new stdlib-urllib core does
  not: it converts every transport failure — connection refused, timeout, non-2xx —
  into TransportError(Exception). The wrapper now also catches the core's
  TransportError, falling back to OSError-only against a pre-TransportError core,
  restoring the retry-once behavior when the service briefly refuses connections during
  a Unity domain reload. The CLI itself has no requests usage or HTTP layer to change.

v2.0.2

Added

• cs setup pins the git source to a major.minor-matched tag — a plain git URL
  (no #fragment) is written to Packages/manifest.json as …git#vX.Y.Z, resolved to
  the newest upstream tag on the CLI's major.minor line, so the manifest records the
  intended version instead of leaving only a commit hash in packages-lock.json. file:
  paths and URLs already carrying a #fragment are written as-is; on a failed tag query
  (offline) setup falls back to the unpinned URL with a warning.

Changed

• Consent before writing the manifest (SKILL.md, references/setup.md) — cs setup
  and --update write the shared, version-controlled Packages/manifest.json; the docs
  now require stating what will be written and getting the user's go-ahead first. The
  read-only commands (cs status, cs health) never need consent.