Linux: /C payload wrapped in double quotes — argv breaks platform parser («Неверные параметры соединения с информационной базой»)

[steel-code-agent]

Summary

Commit 3a49119 "feat(launch): quoted args" introduced quoted_c_arg:

// src/platform/enterprise.rs
fn quoted_c_arg(payload: &str) -> String {
    format!("/C\"{payload}\"")
}

It wraps the /C payload in double quotes and pushes the result as a single argv token. On Linux this breaks every Enterprise launch that uses /C (test runner, Vanessa, MCP).

Reproduction

Run any v8-runner test va / v8-runner launch mcp on Linux. The platform immediately exits with code 1 and writes to /Out:

Неверные или отсутствующие параметры соединения с информационной базой

strace -f -e execve confirms the cv8c argv:

execve("/opt/1cv8/x86_64/8.3.27.2074/1cv8c",
  ["1cv8c", "ENTERPRISE", "/DisableStartupDialogs",
   "/IBConnectionString", "Srvr='onec-infra';Ref='gbig_pam_ai';",
   "/N", "AgentAI", "/P", "***", "/UC", "***",
   "/Execute", ".../vanessa-automation.epf",
   "/C\"StartFeaturePlayer;VAParams=...;mcpMode=ws;manager_url=...;...\"",   ← problem
   "/TESTMANAGER", "/Out", ".../enterprise.out.log"], ...)

The literal " characters end up inside the argv value, so cv8c sees an unknown key starting with /C"… and aborts.

Root cause

Double quotes around /C"..." are a shell convention used to glue a payload with spaces / ; / = into one cmd-line word. std::process::Command bypasses the shell on both Linux (execve) and Windows (CreateProcess) — argv tokens are already split, so adding quotes inserts them into the value itself rather than grouping anything.

The platform parser does not strip surrounding quotes from individual argv tokens; it expects:

"/CStartFeaturePlayer;VAParams=...;..."

This is consistent with how /N, /P, /UC, /Execute are already emitted by V8Connection::args() and build_launch_args — none of them are wrapped in "...".

Verified

1. Manual 1cv8c ENTERPRISE … /C"StartFeaturePlayer;…" from bash → bash strips the outer quotes, cv8c receives /CStartFeaturePlayer;…, parsing succeeds.
2. The same string emitted by v8-runner via Command::arg → quotes remain, parsing fails.
3. Pre-3a49119 history shows /C was emitted as /C + payload glued together, without quoting.

Suggested fix

fn quoted_c_arg(payload: &str) -> String {
    // argv goes to cv8c via execve/CreateProcess, not via a shell,
    // so the payload must NOT be wrapped in double quotes — otherwise
    // the platform parser sees a single unknown key `/C"…"`.
    format!("/C{payload}")
}

Tests that assert "/C\"…\"" should be updated to "/C…" (positive assertions in src/platform/enterprise.rs, src/use_cases/launch_app.rs, tests/cli_launch.rs). Negative --raw-key /C"…" tests in tests/cli_launch.rs and tests/cli_test.rs should stay — they validate rejection of user-supplied raw /C.

Impact

This is a hard regression of all Linux test/Vanessa/MCP runs since the commit was merged (May 1, 2026). Locally patched in our downstream fork to unblock work; happy to send a PR if useful.

Environment

• platform: 8.3.27.2074 (Linux server)
• runner: v8-runner-rust b04926f (latest master at the time of report)
• OS: Ubuntu 22.04 (devcontainer)

[SteelMorgan]

#6 - вот здесь как раз исправление уже прислали

[steel-code-agent]

Closing as duplicate of #6 (@Kyrales, fix_yaxunit) — same root cause, same fix (split /C and payload into two argv tokens).

I missed PR #6 before opening this — the Windows-side YAxUnit symptom there and the Linux-side «Неверные или отсутствующие параметры соединения с информационной базой» here are the same bug: Command::arg(format!("/C\"{}\"", payload)) puts literal quotes inside an argv token, and neither execve (Linux) nor CreateProcess (Windows) strips them.

Verified the PR #6 approach against a 8.3.27.2074 Linux server via strace -e execve: the platform parser accepts the two-token form ("/C", "StartFeaturePlayer;...") and the Vanessa/YAxUnit pipeline reaches StartFeaturePlayer instead of failing at parse time. Posting evidence on #6.