[Feature]: Provider request: Cortex Code (Snowflake) — standard ACP agent, fits existing driver pattern

[kareemscode]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/desktop

Problem or use case

Implementing a new provider, Snowflake's Cortex Code

Proposed solution

What

I'd like to contribute a provider driver for Cortex Code, Snowflake's coding agent CLI.

Why it's a good fit

It plugs into the existing effect-acp + AcpSessionRuntime stack the same way Cursor/Grok/OpenCode do, Verified against the CLI. Some differences, auth is a Snowflake connection, and maybe others discovered during implementation.

Proposed scope

Scope mirrors the Grok driver exactly — new CortexSettings in contracts, CortexDriver/Provider/Adapter/AcpSupport/TextGeneration in apps/server, and web registration (icon, providerDriverMeta, PROVIDER_OPTIONS) — with tests for every module and no changes to shared runtime code.

Why this matters

Would allow T3-Code to be used by more people in more settings. Currently I'm using the cortex code harness which is just fine but would want to have some of the T3 Code benefits with this new provider.

Smallest useful scope

A single provider driver behind the existing ACP stack: CortexAcpSupport (spawn wiring), CortexDriver/CortexProvider (status + registration in builtInDrivers.ts), and a CortexSettings contract with just binaryPath and an optional connection field. The adapter reuses AcpSessionRuntime unchanged, and models are discovered dynamically via ACP configOptions, so no static catalog or custom extension code. Web-side additions could be deferred to a follow-up PR — the minimum is that Cortex appears as a selectable, working provider.

Alternatives considered

Considered maintaining this as a fork-only driver (ProviderDriverKind is open, so it works), but there's no external plugin mechanism, so the driver would need constant rebasing against upstream. A non-ACP custom integration makes no sense given Cortex ships standard ACP. Upstreaming a driver that mirrors the existing Grok pattern seemed like the lowest-maintenance option for both sides.

Risks or tradeoffs

Main tradeoff: maintainers can't test this without a Snowflake account, so CI coverage is mocked and real-world regressions would surface via users — I do plan on using quite a bit, I can contribute what works for me.

Edge cases:

• Expired/missing Snowflake connections — surface clear status errors, not generic spawn failures
• Model catalog varies by account entitlements — default to auto
• Large available_commands_update payload on session start
• Handshake/session setup verified spec-standard ACP; full prompt turn (streaming/permissions/stop reasons) to - be validated before the PR

Examples or references

No response

Contribution

• I would be open to helping implement this.

[sti0]

I already have this running in my fork, built exactly the way you describe — ACP over cortex acp serve. It's essentially the Cursor path with a handful of Cortex-specific adjustments. Verified against Cortex Code v1.1.78.

Three things Cortex does differently:

• Models aren't ACP models. Cortex exposes them as a model configuration option, so selection goes through session/set_config_option and the valid ids are read back from the running session. A static model list would silently rot with the next Cortex release.
• The probe has to tell "login expired" from "connection fine" itself. An unusable connection doesn't fail the session — Cortex starts either way, so the start-failure signal Cursor and Grok rely on doesn't exist. The discriminator is whether the setup response carries a model option; cortex connections list supplies the identity for the provider card.
• The built-in SQL tool runs inside the Cortex process, not through ACP → T3 Code can't put it into read-only mode. --sql-read-only is rejected by acp serve, and CORTEX_CLIENT_READ_ONLY is a Snowflake session parameter Cortex sets itself, not an env var. The real boundary is a --connection whose role holds no write grants — that also covers the bash and Python paths.

On your testability point: the test suite needs no Snowflake account at all — a temp stand-in answers --version and connections list, and acp serve goes to the shared ACP mock agent, including the "connection unusable" case. A real account is only needed to confirm those recorded assumptions still hold after a Cortex release.

Please find a few screenshots attached

Happy to contribute this back to this great project if @t3dotgg and @juliusmarminge want it upstream.