Error on cursor desktop - The request signature we calculated does not match the signature you provided

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’m using bedrock as a proxy and configured cursor to use it.
Only happened in cursor desktop with opus 4.6 high model. “Auto” mode works.
Request ID: 718117f5-0cc7-4220-a2b5-5d6dc626369b
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“Provider returned error: {"message":"The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details."}”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error Provider returned error: {“message”:“The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.”}
$Ai: Provider Error Provider returned error: {“message”:“The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.”}
at p9A (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34267:23670)
at h9A (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34267:22658)
at w9A (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34268:6285)
at rau.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34268:10400)
at async GOa.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:46834:10206)
at async _5u.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:46888:9277)
at async _5u.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:46888:13663)
at async vMe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:34329:17597)
at async Ea (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:45813:4826)

Steps to Reproduce

See request Id, submitted api gateway → lambda → bedrock →

Expected Behavior

Should return valid response

Operating System

MacOS

Version Information

Version: 2.6.21 (Universal)
VSCode Version: 1.105.1
Commit: fea2f546c979a0a4ad1deab23552a43568807590
Date: 2026-03-21T22:09:10.098Z
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

opus 4.6 high

For AI issues: add Request ID with privacy disabled

Request Id: 718117f5-0cc7-4220-a2b5-5d6dc626369b

Does this stop you from using Cursor

Yes - Cursor is unusable

Hi @Tal_Maayani,

This error is coming from your custom proxy (CloudFront → API Gateway → Lambda → Bedrock), not from Cursor’s backend.

When you select opus 4.6 high, Cursor sends "model": "claude-4.6-opus-high" to your proxy endpoint. Your Lambda needs to map that to the correct Bedrock model ID and sign the request accordingly. Since this is a newer model, your proxy’s mapping likely doesn’t include it yet.

Auto mode works because it routes through Cursor’s own infrastructure, bypassing your proxy.

Fix: Update your Lambda to handle claude-4.6-opus-high. You can find the correct Bedrock model ID for your region with:

aws bedrock list-foundation-models --region=<your-region> --by-provider anthropic --query "modelSummaries[*].modelId"

Alternatively, Cursor has a native AWS Bedrock integration that handles model mapping and signing automatically via IAM roles, thereby avoiding the need to maintain a custom proxy.