Point the Claude Code and Codex VS Code extensions at Unity Gateway

[GirishS2093]

Both extensions start their agent themselves rather than through ug claude / ug codex, so they never see ug's gateway settings and ask for an Anthropic or ChatGPT sign-in. Two commits:

Claude Code extension

• New stdlib-only console script ug-claude-vscode, used as claudeCode.claudeProcessWrapper: it runs the Claude binary the extension passes and adds ug's --settings.
• When ug configure sets up Claude Code, it finds every VS Code / Insiders profile with the extension (via globalStorage/storage.json and each profile's extensions.json) plus the VS Code Server's Machine settings, on Windows, macOS and Linux, and sets claudeProcessWrapper, disableLoginPrompt and (if unset) initialPermissionMode.
• Leaves settings.json files with comments alone (prints the lines to add) and never replaces a wrapper that isn't ug's; --dry-run writes nothing; ug revert removes only what ug added.

Codex extension

• The extension runs its own bundled Codex, which reads only Codex's config files. On Linux/macOS ug's /etc/codex/managed_config.toml already covers it; on Windows (and when that privileged write is skipped) nothing does.
• When Codex is configured and any VS Code profile has openai.chatgpt, ug writes the keys it puts in the machine-wide file (model_provider, the admin's default model, [model_providers.Databricks]) into ~/.codex/config.toml, unless the machine-wide file already points at this gateway. This copy waits 30 s for ug auth-token (the extension's Codex starts it while starting itself; on Windows that took 8–9 s, so every request timed out at 5 s).
• A foreign model_provider is left alone with a warning; --dry-run writes nothing; ug revert removes only those keys and restores a previous model.

Tests: tests/test_vscode.py, tests/test_vscode_wrapper.py, TestVSCodeExtension in test_agent_codex.py (18), CLI revert wiring. Checked on Windows 11 against real VS Code profiles, with the real Claude CLI through the wrapper (including the stream-JSON exchange the extension uses), and with the Codex extension's bundled Codex (0.155) through the gateway, confirmed in a live VS Code window; on WSL the extension's Linux Codex used /etc/codex/managed_config.toml.

Related: #808 writes Claude's gateway settings to ~/.claude/settings.json when the managed file can't be written, so the IDE extension keeps using the gateway. Worth agreeing which approach upstream wants for the Claude extension.

Integration tests: none (needs VS Code in CI). A configure-level journey with a fake VS Code profile directory as scenario input is possible if wanted.

Results: on its own on Windows 11, 76 VS Code/extension tests pass; on Linux lint passes and the unit suite matches main (2920 passed; the same 4 environmental user-agent failures).

Update, 11 Oct: rebased onto main (3754d13), plus two follow-up commits found while using the extensions with an admin-managed config:

• Replace a Claude Code extension wrapper that no longer exists. ug still leaves a working foreign claudeCode.claudeProcessWrapper alone. But a wrapper whose file is gone (for example a hand-made one that was uninstalled) only makes the extension fail with "Claude Code native binary not found", so ug now takes that setting over, says so, and ug revert removes it instead of restoring the dead path.
• Route the Codex extension through a provider or Unity Catalog schema. With a Model Provider Service (admin-managed or --provider) or a Unity Catalog schema, ug codex adds the routing header at launch and publishes that source's model list. The extension never launches through ug, so its config.toml copy had no routing header: with a managed Azure OpenAI provider its requests skipped the provider and failed, and its model list stayed on the previous source. The copy now carries the routing header, and ug configure publishes the routed model list too (a failure only warns). ug's own files still keep launch routing headers out.

ug-claude-vscode now starts Claude through ucode.os_compatibility.subprocess_cross_os.run, per main's new lint rule.

Results after the update (ruff check, ruff format --check, ty check src/, pytest --ignore=tests/test_e2e.py): on Linux (Ubuntu on WSL) lint ok, 4069 passed, 1 failed (the OpenCode user-agent e2e test, which fails on main here too). On Windows 11 together with #873: lint ok, 4009 passed, 2 failed (the OpenCode user-agent e2e test and one test unrelated to this PR); the extension tests also pass on Windows with this PR alone.

🤖 Generated with Claude Code