I’m realizing there’s a fundamental issue here—Cursor’s agent shells are non-interactive and non-login, which means they won’t source either .bash_profile or .bashrc, so adding the API keys to .bash_profile won’t actually work for loading environment variables in the agent context.
However, the user is pushing back on the ~/.aws/credentials approach and wants to try .bash_profile instead. I should clarify what actually gets sourced by Cursor’s different shell contexts—the integrated terminal versus the agent tool-call shell—and explain why the .bash_profile approach won’t solve the agent’s credential problem, while still respecting their direction.
Steps to Reproduce
AWS api keys are not being picked up in .bashrc nor .bash_profile, so aws cli errors
Agent shells actually do source .bashrc and .bash_profile - but only once, when the agent session initializes. The init shell runs as a login + interactive shell, so both files get loaded. After that, each command runs in a simpler shell that restores a snapshot of the environment captured during init, without re-reading the profile files.
So if you added AWS credentials to your profiles after starting the session, the snapshot won’t include them. A few things to try:
Restart Cursor after modifying your profile files - this forces a fresh init that captures the new exports
Check that .bash_profile sources .bashrc - on some Linux distros these are separate. If your creds are in .bashrc but .bash_profile doesn’t source it, the login shell init won’t pick them up
Check for early-exit guards in .bashrc - some distros include [ -z "$PS1" ] && return near the top, which can skip the rest of the file in non-standard shell contexts
For AWS specifically, ~/.aws/credentials (or ~/.aws/config with named profiles) is the most reliable approach. The AWS CLI reads these files directly regardless of how the shell was started, so there’s no dependency on environment variable sourcing.
no, i have had it in my .bashrc for a while, and it continues to not pick up the credentials even though it works in my terminal sessions. I think this is a bug