Before submitting
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
Before submitting
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:
Examples or references
No response
Contribution