ci: zod MCP schema gate + codex-desktop release reminder

[avifenesh]

Why

Follow-up to #1. The boolean outputSchema regression was only catchable by the in-house mcp_safety_check.py heuristics, not by the actual validation strict clients run. This adds a real zod gate using @modelcontextprotocol/sdk so the exact failure can never ship again, plus a release-time reminder to keep codex-desktop-linux in sync.

What

zod schema validation (both pre- and post-release)

• scripts/zod-check/ — self-contained Node ESM check that does the MCP initialize handshake, calls tools/list, and parses the result with ListToolsResultSchema (the same AssertObjectSchema path that rejected received: true in Bug: outputSchema.properties.received is true (boolean) causing Zod validation failure in MCP clients #1). CI-only; excluded from the published npm files.
• zod-schema job — pre-release gate against the locally built binary; added to release-binary.needs, so a broken schema blocks publish.
• validate-published job — runs after publish-npm, installs the published @agent-sh/computer-use-linux@<version> and re-runs the zod check against it.

release reminder

• notify-codex-desktop job — on a v* tag, opens an issue in this repo reminding to sync codex-desktop-linux with the release content (extracts the matching CHANGELOG section). Uses the default GITHUB_TOKEN (issues: write); dedupes by title.

Verification (local)

• Positive: node scripts/zod-check/check.mjs against the v0.2.2 binary → OK: 16 tools validated.
• Negative: feeding ListToolsResultSchema a { properties: { received: true } } node throws ZodError with the path pointing at received — i.e. the guard catches the exact Bug: outputSchema.properties.received is true (boolean) causing Zod validation failure in MCP clients #1 shape.
• ci.yml parses; 15 jobs.

[gemini-code-assist]

Code Review

This pull request introduces a regression guard for MCP tool list responses by adding a Node.js script that validates server output against Zod schemas. The script performs an initialization handshake and parses the tool list to ensure compatibility with strict clients. Review feedback suggested improving the robustness of the script by refining command-line argument parsing to handle missing values and ensuring safe UTF-8 processing of the server's stdout stream by explicitly setting the encoding.

[gemini-code-assist]

The parseArgs function does not handle cases where --command is provided without a following value (e.g., as the last argument). This results in args.command being set to undefined, which causes spawn to throw a TypeError synchronously. Adding a check for the existence of the next argument makes the script more robust.

function parseArgs(argv) {
  const args = { command: 'target/debug/computer-use-linux' };
  for (let i = 0; i < argv.length; i += 1) {
    if (argv[i] === '--command' && argv[i + 1]) {
      args.command = argv[i + 1];
      i += 1;
    }
  }
  return args;
}

[gemini-code-assist]

It is safer to set the encoding on the stdout stream to 'utf8'. This ensures that the 'data' event emits strings and correctly handles multi-byte UTF-8 characters that might be split across chunk boundaries. Using chunk.toString('utf8') on raw buffers can occasionally lead to corrupted characters if the split happens in the middle of a multi-byte sequence.

const child = spawn(command, ['mcp'], { stdio: ['pipe', 'pipe', 'inherit'] });
child.stdout.setEncoding('utf8');

[gemini-code-assist]

With stdout encoding set to 'utf8', the chunk is already a string. You can append it directly to the buffer, which is cleaner and avoids redundant toString() calls.

child.stdout.on('data', (chunk) => {
  buffer += chunk;

[avifenesh]

Addressed the gemini-code-assist review in 0f4aec9's follow-up:

• parseArgs now ignores a trailing --command with no value (falls back to the default) instead of passing undefined to spawn.
• child.stdout.setEncoding('utf8') + direct chunk append, so multi-byte UTF-8 split across chunks decodes correctly.

CodeQL flagged dtolnay/rust-toolchain@stable and Swatinem/rust-cache@v2 as unpinned — these match the existing convention across every job in ci.yml and predate this PR, so pinning is left to a separate repo-wide pass.