Switch AWS Profiles per Workspace on macOS: One Hotkey, Right Credentials

Q: Does it support AWS IAM Identity Center (SSO)?

Yes. SSO profiles defined in `~/.aws/config` as `[profile NAME]` show up in the dropdown like any other. AWS CLI handles the sign-in flow on first use. Note: `[sso-session NAME]` blocks themselves aren't pickable in the dropdown (they're not profiles, they're shared config), which matches AWS CLI's own behavior.

Q: Can I still use `aws-vault`?

Yes. `aws-vault exec my-profile -- some-command` reads `AWS_PROFILE` from the environment, so the workspace binding still helps even when you layer it on top.

Bind an AWS profile to each ShiftPlus workspace. Switch workspaces and every new terminal already has the right AWS_PROFILE exported, with no dotfile edits, no direnv, no aws-vault ceremony.

Switch AWS Profiles per Workspace on macOS: One Hotkey, Right Credentials

If you work across multiple AWS accounts (dev, staging, prod, plus a couple of client environments), you probably spend more of your day typing export AWS_PROFILE=… than you'd care to admit. Forget once and you're suddenly running terraform plan against the wrong account.

ShiftPlus now lets you bind an AWS profile to each workspace. Switch workspaces with your hotkey, and every new terminal you spawn from that workspace already has the right AWS_PROFILE exported. No editing dotfiles, no direnv config, no aws-vault ceremony.

The problem with manual AWS profile switching

If you have profiles in ~/.aws/config for multiple accounts, your options today are roughly:

Approach	Friction
`export AWS_PROFILE=dev` in each terminal	Forget once, run `terraform apply` against prod
`direnv` + `.envrc` per project folder	Per-folder, not per-context; doesn't follow you across apps
`aws-vault exec dev -- …` per command	Verbose; re-prompts when the cache expires
Custom shell function + `aws sts get-caller-identity`	DIY, fragile, every dev rebuilds it from scratch

The core problem: AWS profile selection lives at the shell layer, but your intent ("I'm working on the Acme account right now") lives at the project layer. ShiftPlus's workspace model gives you somewhere to bind the two.

How it works

A ShiftPlus workspace already bundles your apps, browser profiles, window layout, and environment variables. The new AWS dropdown is a typed, friendlier way to set the AWS_PROFILE env var per workspace, populated from profiles that already exist on your Mac, instead of free-text.

When you switch into a workspace and launch a terminal (Terminal.app, iTerm/iTerm2, Warp, Alacritty, Hyper, Kitty, Tabby, or WezTerm are all detected automatically), ShiftPlus prepends export AWS_PROFILE='your-profile' && … to the shell command. From that point on, every AWS CLI call, every Terraform run, every boto3 client in that shell picks up the right credentials, because that's the standard env var the entire AWS toolchain already reads.

Nothing in ~/.aws/ is written or modified. ShiftPlus only reads the INI section headers from your config files to populate the dropdown.

Setting it up

Open the workspace settings for the project you want to bind a profile to.
Scroll to the Environment section. You'll see a row called AWS_PROFILE with a dropdown control.
Pick a profile. The list is populated from ~/.aws/config and ~/.aws/credentials:
- 0 profiles: hint to run aws configure first.
- 1 profile: auto-selected.
- 2–5 profiles: simple popover list.
- 6+ profiles: searchable type-ahead, so you can type prod to filter.
Save the workspace.
Switch to that workspace with your hotkey, open a new terminal, and run aws sts get-caller-identity. You should see the IAM identity for the profile you just bound.

Repeat per workspace. A typical setup: client-acme → acme-prod, client-acme-staging → acme-staging, side-project → personal. Each one a single hotkey away.

Privacy: how we read your AWS files

This is the part developers tend to (rightly) want clear answers on.

ShiftPlus reads ~/.aws/config and ~/.aws/credentials to populate the dropdown. The parser only matches INI section headers (the [default] and [profile name] lines) using a regex of shape ^\s*\[([^\]]+)\]\s*$. Every other line, including aws_access_key_id, aws_secret_access_key, and aws_session_token, is iterated past and never returned, stored, copied, or logged.

There's a regression test in the codebase (AWSProfileLoaderTests.test_parse_credentials_neverReturnsSecretValues) that fails the build if the parser ever leaks credential material into the returned list. The guarantee isn't just a comment in a README; it's enforced at CI time.

What syncs via iCloud: only the profile name string (e.g., "acme-prod"). Your actual access keys never leave the original Mac's ~/.aws/credentials. If your second Mac doesn't have that profile in its own AWS config, AWS CLI will surface the standard error and you can aws configure there.

One scoping note: this privacy guarantee covers the AWS profile dropdown specifically. If you type secrets directly into a generic env-var row (e.g., API_SECRET=…), those do sync via iCloud, and ShiftPlus shows an inline warning when it detects a likely secret in a free-text env-var field.

What works, and what doesn't

Works:

Static access keys, SSO profiles, role assumption: anything AWS CLI itself handles. ShiftPlus just sets the profile name; AWS CLI does the rest.
Custom paths via AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE env vars, with ~ expansion.
All eight terminal emulators above; identical export-string format across them.

Doesn't:

Already-running terminals. AWS_PROFILE is exported into shells spawned after the workspace switch. Existing tabs keep whatever they had; close them and reopen from the new workspace if you want the new profile.
Region. AWS_REGION isn't auto-set. If your profile doesn't already pin a region in ~/.aws/config, add AWS_REGION as a separate env-var row in the same workspace.

FAQ

Does ShiftPlus modify my ~/.aws/ files?

No. The loader is read-only and only inspects INI section headers.

Does it support AWS IAM Identity Center (SSO)?

Yes. SSO profiles defined in ~/.aws/config as [profile NAME] show up in the dropdown like any other. AWS CLI handles the sign-in flow on first use. Note: [sso-session NAME] blocks themselves aren't pickable in the dropdown (they're not profiles, they're shared config), which matches AWS CLI's own behavior.

What if I delete a profile from ~/.aws/config after binding it?

The stored name stays in the workspace until you change it. The shell will still receive AWS_PROFILE=stale-name, and AWS CLI will reject the call when used. Surfacing a warning in this case is on the roadmap; feedback welcome.

Can I still use aws-vault?

Yes. aws-vault exec my-profile -- some-command reads AWS_PROFILE from the environment, so the workspace binding still helps even when you layer it on top.

Do I need Pro to use this?

The AWS profile dropdown itself isn't gated: configure it freely on any workspace. What requires Pro after your free trial ends is workspace switching itself. So during the trial, the full feature works end-to-end. After the trial without Pro, your AWS profile settings are still there, but you'll need to upgrade to keep switching between workspaces (which is what fires the env-var change in the first place).

Try it

The AWS profile dropdown ships in the current ShiftPlus build. Open any workspace's settings and look for AWS_PROFILE in the Environment section.

If you don't have ShiftPlus yet, download here or see pricing.