[P1] Add Saved Connection Profiles

[sajeetharan]

Feature Request

Priority: P1 (High)

Description

CosmosDB Shell has no way to save, list, or switch between named connection profiles. Power users managing multiple accounts/environments must re-type connection strings each time.

Comparable Features in Other Shells

• sqlcmd: sqlcmd config subcommands (config view, config use-context)

Proposed Behavior

Add a profile or config command:

• profile save <name> — Save current connection as a named profile
• profile list — List saved profiles
• profile use <name> — Connect using a saved profile
• profile delete <name> — Remove a saved profile
• Store profiles securely (credential store integration or encrypted file)

Example Usage

connect --connect "AccountEndpoint=..." --connect-mode direct
profile save prod-account

profile list
profile use dev-account

[mkrueger]

what does a profile include other than the connection?

It's not that easy to do that - I feel this is more a feature that is out of scope on that level - why not having two shells open with different "profiles"?

[sevoku]

Looks like a nice convenience feature to me... we could save name:"connection parameters" keypairs and have something like "connect --profile xyz". Don'T think it's that hard to implement. I wouldn't even introduce a separate command for that.

connect save [name] would save the current connection params with the key name
connect --profile [name] would connect with the params saved under that profile name.

But a separate profile command that would manage that store would be nice as well.

Stored in ~/.cosmosdbshell-profiles, as json or simple key=value pair per line.

[tnaum-ms]

The tricky part here is secrets. Connection strings contain account keys or tokens, and whatever "secure storage" means in practice depends heavily on the platform.

.NET does not have a single built-in cross-platform secure credential store. On Windows you can lean on DPAPI or the Windows Credential Manager, on macOS the Keychain, and on Linux it fragments quickly: libsecret works if the Secret Service is available, but that is far from guaranteed across distros and environments. Rolling your own encryption does not really help because you still have to store the encryption key somewhere, which just shifts the problem.

This also makes the security review significantly heavier. Right now the shell makes no claims about credential storage, so the surface area is clean. The moment we start persisting secrets, we own that story end to end and can no longer simply say we inherit VS Code's or the OS's security model.

Not saying it should not be done, but it is worth going in with eyes open: this is not a "save to a config file" task, it is a proper cross-platform secure storage problem, and getting it right on all three platforms without introducing a fragile dependency is a meaningful time investment. Worth scoping carefully before picking it up.

[mkrueger]

And you've to authenticate potentially every time.

If you want that - open more than one shell - then you can switch easily between "profiles" without command. Doesn't really make sense to me.

Yeah you need "connection strings" - true - but saving connection strings in the options is something I do not really think it's a good idea or gives any benefit. Users can do connect scripts if they want an easier way. Profiles are just connection strings.

[sevoku]

Tomasz Naumowicz (@tnaum-ms) to avoid this all I'd just strip account keys from profiles and let the command prompt for a key, store only the auth type alongside the endpoint. We definitely should not sign up for the whole secure-store story.

Mike Krüger (@mkrueger) it's not about opening different shells simultanously but being able to switch between accounts without needing to memorise the connection strings all the time. It's a different problem.

Sajeetharan (@sajeetharan) even though I agree it's a nice feature, let's lower the priority. We can keep this around and see whether there is demand for this.

[mkrueger]

If you don't memorize it just make a script.

Or use the history - ctrl+r "connect" -> done

[sajeetharan]

Agentic & Automation Roadmap framing (item A2)

This maps to A2 — Saved connection profiles + headless auth in the draft agentic roadmap (docs/agentic-roadmap.md). Beyond interactive convenience, saved profiles are a prerequisite for automation/CI and agent scenarios: with 60+ accounts and multi-environment enterprise users in telemetry, re-typing connection details blocks headless runs.

Per the discussion here, the recommended scope is to avoid secret storage — persist only endpoint + auth mode (no keys), and resolve credentials via Entra at connect time. Pairs well with the session audit log (#TBD, item G4).

[KhushviB]

Hi Sajeetharan (@sajeetharan), I'm picking up A1 (#155) and would like to take on A2 as well to keep the roadmap moving.

Based on the discussion here, I understand the recommended scope: avoid secret storage, persist only endpoint + auth-mode (no keys), resolve credentials via Entra at connect time.

My plan:

1. Add profile save <name> : stores current endpoint + auth-mode to ~/.cosmosdbshell-profiles as key-value pairs
2. Add profile list : reads and displays saved profiles
3. Add profile use <name> : loads a profile and connects
4. Add profile delete <name> : removes a saved profile
5. No credential storage : Entra resolves auth at connect time

This pairs naturally with A1 since saved profiles become most useful once output is scriptable and portable across CI environments.

Happy to start once A1 is underway. Should I coordinate timing with you or proceed in parallel?