Antigravity on Windows: dangling config/skills junction breaks session/new (fix inside) + ZCode provider feature request #27976

Two things in one report: a Windows Antigravity bug with a verified workaround, and a feature request.

Part 1 — Bug: session/new fails with "Cannot create a file when that file already exists" (dangling config/skills junction)

Environment: T3 Code 0.1.6-nightly.20261030.3917, Windows 11 x64 (build 26200), Antigravity runtime agy-acp-server 1.4.1 (managed install). Google endpoints are only reachable via a local proxy (HTTPS_PROXY set for the app process tree).

What happens

1. Provider setup creates the profile at %USERPROFILE%\.t3\userdata\providers\antigravity\<hash>\ and links skills via a junction: <profile>\config\skills → %USERPROFILE%\.gemini\config\skills. The junction target is never created, so the link dangles.

2. On first use, agy_acp_server.exe handles initialize fine (38–46 s), auth succeeds (silent token refresh + loadCodeAssist OK, tier "Antigravity" free) — but session/new returns:

   {"code":-32603,"message":"Internal error","data":{"details":"Failed to initialize conversation ... failed to create workspace folder \"...config/skills\": mkdir ...: Cannot create a file when that file already exists."}}

   The runtime sees the directory as missing (dangling reparse point → exists() returns false), calls mkdir, and Windows rejects with ERROR_ALREADY_EXISTS because the junction itself exists.

3. The UI surfaces this as: "Antigravity authenticated, but could not initialize a session or load models."

Workaround (verified): create the junction target manually:

mkdir "%USERPROFILE%\.gemini\config\skills"

After that, session/new succeeds immediately and models/modes load.

Suggested fix: in linkAntigravityUserSkills, create the target directory if missing before creating the junction — or treat ERROR_ALREADY_EXISTS on an existing reparse point as success.

Related: live updates garbled / missing until reload

With Antigravity sessions, live updates don't render in the desktop UI — the assistant reply only appears after leaving and re-entering the session (it persists correctly in the trajectory DB). During streaming, CJK text renders as mojibake, which looks like per-chunk UTF-8 decoding of streamed deltas (chunk boundaries splitting multibyte characters).

Part 2 — Feature request: ZCode provider

ZCode (Z.AI's coding agent; Windows/macOS desktop + CLI) ships a stdio app-server, structurally very close to codex app-server:

zcode app-server   # "ZCode Protocol" v1, line-delimited JSON over stdio

It is not ACP, but the protocol is simple. Notes from probing CLI v0.17.1:

• Framing: line-delimited JSON without the jsonrpc envelope — requests {"id", "method", "params"}, responses {"id", "result"|"error"}, notifications {"method", "params"}. Schemas are strict (unknown keys rejected).
• Session lifecycle:
  • session/create {workspace: {workspaceKey, workspacePath}} → the server asks the client back: session/requestRuntimePreferences (answering {"nativeSearchEnhancementsEnabled": false} is sufficient) → result: {session: {sessionId: "sess_…", model}, protocol: {name: "ZCode Protocol", version: 1}}
  • session/send {sessionId, content} → {accepted: true}
  • events: state.updated, computer-use/operation-event (turn-started/turn-completed); final content via session/messages {sessionId}
  • plus session/list, session/resume, session/fork, session/setModel … (22 session/* methods total)
• The model comes from the local provider settings, so it works with custom OpenAI-compatible gateways.

Would you consider adding a ZCode driver? Happy to share more protocol details — I've mapped the full method catalog (~85 methods) from the CLI bundle.