When uploading a PEM key as an evironment secret for cloud agents the only thing that gets saved is the first line -----Begin secret key-----.
Everything after the new line (even if a literal \n) is getting removed and the cloud agent cannot see the reset of it. The UI will show the whole key, but there must be a bug with uploading them.
Steps to Reproduce
Copy and paste a PEM key into the cloud agents secrets space. Ask a cloud agent to do something that would require the PEM key, the only thing they will see is the first line and so whatever requires that PEM key (i.e. Github) requests will fail.
Expected Behavior
I would like to be able to upload a PEM key, or a single line PEM with literal \n and have the entire string be useable for the agent.
Hey, thanks for the detailed report. This looks like a known issue. Some secret input surfaces cut a multi-line value after the first line, so the agent gets an invalid key. Literal \n also don’t get expanded, so a single-line version doesn’t help.
Here are two working workarounds while we’re fixing it:
Add the key via cursor.com dashboard → Cloud Agents → Add Secrets. The Value field there keeps line breaks, so the full multi-line PEM is saved. Don’t edit the value later using the edit dialog, it will flatten it again.
Alternative option: store the key as base64 (base64 < key.pem) and decode it on the VM inside the agent. That way the value stays single-line on any surface and won’t get cut.
Let me know if the dashboard also isn’t saving it correctly.
Hey Dean! Thank you! I tried both and the cloud agents reported no success. I’m wondering if naming the key the same thing causes some kind of caching issue so I was thinking of trying to name it something else just to test.
I’ll report back on that test, but yes the dashboard upload also seems to be truncating it at the moment.
Thanks for testing. The fact that the base64 version didn’t work either is an interesting signal. Base64 is always a single line and physically can’t get truncated, so if it still doesn’t produce a working key, the issue might not be value truncation. It might be that the secret isn’t reaching the VM fully, or isn’t reaching it at all.
Let’s separate these cases first. Ask the cloud agent to print not the key itself, but its length and number of lines, for example:
if the byte count is small about the length of the -----BEGIN...----- line, the value really is getting cut off on input
if the variable is empty or missing, the secret isn’t being injected into the VM, that’s a different issue
if the length is full, the value arrives intact and the problem is something else
A couple clarifying questions:
For base64, what command did the agent use to decode it back on the VM? Usually it’s something like echo "$SECRET_NAME" | base64 -d > key.pem. If that step wasn’t done, the key will still be base64.
Your idea to rename the secret is good, try that. Also, did you add the key in the dashboard via Add Secrets, or did you edit an existing one via the edit dialog? The second path might collapse the value into one line again.
Send what wc -c and wc -l show, and we’ll go from there.
And paste that value into a new key that is named something different then it works!
So it looks like our issue is in the existing keys and that deleting and recreating the key with the same name from the dashboard does not update the key.
On the original key it reported 32 and 1 for the wc -c and wc -l commands. This was the case after updating via the dashboard.
Thank you for the help so far Dean! I’ve now got cloud agents making demos about working on a sandboxed cloud agent!
Great debugging, thanks for running wc. That really clears things up.
What you found, wc -c = 32 and wc -l = 1 on the old secret even after updating it in the dashboard, means the agent was still getting the old truncated value, roughly the length of the -----BEGIN...----- line. So the issue was not only that the key got cut off in the first place. Updating the secret under the same name did not propagate to the VM, it kept the previous value. That’s why recreating it under a new name worked.
The working recipe you came up with is solid. I’ll capture it here for anyone who hits the same thing:
Encode the key to base64 as a single line: base64 -i /path/to/private-key.pem | tr -d '\n' | pbcopy
Create a secret with a new name in cursor.com dashboard → Cloud Agents → Add Secrets and paste the base64 value there. A single line won’t get cut in any form.
On the VM, decode it back: echo "$SECRET_NAME" | base64 -d > key.pem
When rotating the key, use a fresh secret name instead of editing the existing one. This avoids getting stuck with a stale value.
I shared the stale value issue on updates under the same name with the team. Glad Cloud Agents are already running demos in the sandbox. If you hit anything else with secrets, drop it in the thread.