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
That’s helpful, it rules out the timing issue I mentioned.
Here’s what’s actually going on. Your terminal and the agent start bash in different modes:
Your integrated terminal runs as a non-login shell, which reads ~/.bashrc. That’s why your credentials work there.
The agent starts its shell as a login shell, which reads ~/.bash_profile (or ~/.bash_login / ~/.profile) and does not read ~/.bashrc unless one of those files sources it.
So with your credentials in ~/.bashrc and a ~/.bash_profile that doesn’t source it, the agent’s shell never loads them — even though your terminal does. This is standard bash behavior for login vs non-login shells rather than something specific to Cursor.
The fix is one line. Add this to your ~/.bash_profile:
[ -f ~/.bashrc ] && . ~/.bashrc
Then restart Cursor so the agent shell re-initializes. After that it’ll pick up everything in ~/.bashrc.
For AWS specifically, ~/.aws/credentials is still the most robust option, since the CLI reads it directly no matter how the shell was started.