Repository navigation
[P1] Add Saved Connection Profiles #104
Description
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 configsubcommands (config view,config use-context)
Proposed Behavior
Add a profile or config command:
profile save <name>— Save current connection as a named profileprofile list— List saved profilesprofile use <name>— Connect using a saved profileprofile 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
Activity
mkrueger commentedon Jun 4, 2026
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 commentedon Jun 4, 2026
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 keynameconnect --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 commentedon Jun 5, 2026
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 commentedon Jun 5, 2026
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 commentedon Jun 5, 2026
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 commentedon Jun 8, 2026
If you don't memorize it just make a script.
Or use the history - ctrl+r "connect" -> done
sajeetharan commentedon Jul 6, 2026
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 commentedon Jul 6, 2026
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:
profile save <name>: stores current endpoint + auth-mode to~/.cosmosdbshell-profilesas key-value pairsprofile list: reads and displays saved profilesprofile use <name>: loads a profile and connectsprofile delete <name>: removes a saved profileThis 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?