Repository navigation
Description
Description
Blocking V1 → V2 regression: SAP AI Core is unusable through the normal /connect / saved-credential workflow. A valid service key works in V1, but after entering the same key in compiled V2, model requests fail because the key never reaches the SAP SDK.
This is not an invalid-token problem or a cosmetic error. For users relying on saved credentials, with no AICORE_SERVICE_KEY or service binding configured, SAP AI Core cannot authenticate any model request. The authentication message sends users toward debugging or replacing credentials that are already valid. Please prioritize this as a provider-blocking regression.
SAP AI Core authentication failed: Could not find service credentials for AI Core.
Please check the service binding.
Make sure your AICORE_SERVICE_KEY environment variable is set correctly.
Root cause
The V2 credential producer and consumer disagree on the field name:
packages/core/src/model-resolver.ts,nativeCredentialSettings: a saved key becomes{ apiKey: credential.key }.packages/core/src/aisdk.ts: forwards these settings into SDK options.SapAICorePlugin: reads onlyevt.options.serviceKeyorprocess.env.AICORE_SERVICE_KEY.
Consequently, the saved key exists but the SAP SDK sees no service credentials. The upstream dev SAP hook still contained this mismatch when checked.
Steps to reproduce
- Use a SAP AI Core service-key JSON that works in V1.
- Start a fresh compiled V2 server without
AICORE_SERVICE_KEYorVCAP_SERVICES. - Save the complete key through
/connect→ SAP AI Core. The corresponding API isPOST /api/integration/sap-ai-core/connect/keywith{ "key": "<service-key JSON>" }. - Select a SAP model and send a short prompt.
- The request fails with missing-service-credentials authentication errors despite the valid saved key.
Expected: the documented saved-credential workflow must authenticate without requiring a second manual environment-variable configuration.
Verified differential reproduction
An isolated probe traversed the real ModelResolver.fromCatalogModel → AISDK → SapAICorePlugin → SAP SDK doStream path with the same key, provider package, model (gpt-4.1-mini), and prompt:
| Credential path | Result |
|---|---|
| Saved key, before correction | Resolver passes apiKey; SAP SDK credential absent; authentication fails |
Same key through AICORE_SERVICE_KEY |
Real SAP request succeeds: OK. |
Saved key after changing the hook to read apiKey |
Real SAP request succeeds: OK |
The local correction changes evt.options.serviceKey to evt.options.apiKey, retaining existing explicit environment precedence. Three focused regression tests and core typechecking pass.
A patched compiled-server check also saved the key through the connect API (204) and got past authentication, but then hit a separate LLMEvent.stepFinish schema failure in aisdk.ts when consuming the SAP provider's V2 finish event. This is not a claim that the one-line credential correction makes the entire SAP conversation pipeline healthy; end-to-end verification must also account for that subsequent compatibility blocker.
Related reports / scope
- bug(v2): SAP AI Core initialization fails #54791 is the source-only Babel/Bun initialization crash. This saved-key defect affects the credential path even when a compiled binary avoids that crash.
- bug(provider): credentials set via CLI/
/connectare not applied to a running server (SAP AI Core, GitHub Copilot), and SAP multi-line keys are stored truncated #46354 concerns V1 multiline-key truncation and stale credentials. This reproduction uses the complete valid key in a fresh isolated process, not a truncated or cached key. - bug: AI SDK V2 providers silently lose usage and disable auto-compaction #50338 tracks related AI SDK V2 usage/compatibility problems, distinct from this credential-field mismatch.
Plugins
No user plugins required.
OpenCode version
V2 local checkout with @opencode/core / CLI version 2.0.31; credential-path reproduction and locally compiled verification. This is not a claim that the diagnostic binary is an official published release.
Bun 1.4.2; @jerome-benoit/sap-ai-provider-v2 5.0.3.
Operating System
macOS, Darwin 27.0.0, arm64.
Terminal
Not terminal-specific; verified through isolated SDK and headless HTTP paths.
Activity
opencode-agent commentedon Oct 16, 2026
Thanks for the detailed report. I reproduced this on v2.0.31, which is currently the latest release.
What I did:
opencode servewith noAICORE_SERVICE_KEYorVCAP_SERVICESset.POST /api/integration/sap-ai-core/connect/key, which returned 204. The key pointed at a local mock of the SAP endpoints.opencode run -m sap-ai-core/gpt-4.1-mini "say OK". It failed withSAP AI Core authentication failed: Could not find service credentials for AI Core…, and the mock received no requests, so the saved key was never used.AICORE_SERVICE_KEY, the SDK did request a token from the mock.This matches the mismatch you describe: the resolver passes the saved key as
apiKey, but the SAP hook reads onlyserviceKeyor the env var. The hook is still the same on the latestdev(582c974). Runningdevfrom source fails earlier with the init crash from #54791, so I could only confirm this bug on the release. The script below reproduces it.For now, exporting the key as
AICORE_SERVICE_KEYgets past authentication.Related:
stepFinishfailure you hit after authentication)process.env/connectare not applied to a running server (SAP AI Core, GitHub Copilot), and SAP multi-line keys are stored truncated #46354: v1 credential and truncation issuesReproduction script (repro.sh)
Run it:
bash repro.sh