[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]

@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.

@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 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