Repository navigation
Credential placeholder model breaks SDKs that validate token format before making network calls #894
Description
The placeholder credential model (openshell:resolve:env:*) assumes credentials flow through HTTP requests where the L7 proxy can intercept and substitute real values. This works well for header-based auth, URL path tokens (Telegram), query parameters, and Basic auth.
However, some SDKs validate credential format in-process before making any network call. When the process reads an env var and sees openshell:resolve:env:SLACK_BOT_TOKEN instead of a value matching the expected format (e.g., xoxb-*), the SDK rejects the credential immediately. No HTTP request is made, so the proxy never gets an opportunity to resolve the placeholder.
Concrete case
Slack's @slack/web-api validates the xoxb- prefix on bot tokens and @slack/socket-mode validates the xapp- prefix on app tokens. Both checks happen at initialization, before any network I/O. The placeholder fails validation, and the SDK either throws invalid_auth or silently skips channel initialization.
Scope
This affects any SDK or library that performs client-side credential format validation before its first network call. Slack is the first confirmed case, but the pattern is common — OAuth libraries checking token structure, AWS SDKs validating key format, etc.
Downstream impact
NemoClaw #1569 and #2085 are blocked on this. Slack is one of three messaging channels NemoClaw supports, and it is currently non-functional inside OpenShell sandboxes.
References
- The placeholder model was introduced in refactor: move secret values out of sandbox environment into supervisor-managed placeholders #112
- L7 credential injection was generalized in feat: L7 credential injection for non-inference providers #538 and feat(sandbox): extend L7 credential injection — query params, Basic auth, URL paths #689
- OpenShell provider docs state: "The agent process inside the sandbox never sees real credential values" — this invariant is the root of the conflict
Activity
fix(dockerfile): emit appToken for slack in baked openclaw.json (#2146)
derekwaynecarr commentedon May 11, 2026
In the future, it seems desired that as part of authoring a credential driver we include a plugin mechanism to render obfuscated tokens in a format expected by the given integration.
cjagwani commentedon Aug 12, 2026
OpenShell 0.0.103 endpoint binding makes this a blocker again for endpoint-bound Slack providers.
NemoClaw currently uses the supported provider-shaped aliases
xoxb-OPENSHELL-RESOLVE-ENV-SLACK_BOT_TOKENandxapp-OPENSHELL-RESOLVE-ENV-SLACK_APP_TOKENso Hermes/Slack SDK initialization passes without exposing a real token. After #2510,SecretResolver::resolve_placeholderintentionally rejects those aliases for identity-bound keys because the alias carries no provider revision. The child environment does carry the needed identity inopenshell:resolve:env:vN_KEY, but that form fails Slack's in-processxoxb-/xapp-validation.That leaves no secure working representation for this combination:
Could OpenShell add an identity-bearing, token-format-preserving alias contract (or equivalent credential-driver rendering) that binds the opaque provider revision plus env key and retains the endpoint/epoch checks from #2510? This now blocks NemoClaw's OpenShell 0.0.103 qualification in NVIDIA/NemoClaw#8893.
github-actions commentedon Aug 28, 2026
This issue has had no activity for 14 days and is now marked stale. It may be closed in 7 days if there is no further activity. Comment or remove the state:stale label to keep it open.
nv-nedelman-1 commentedon Sep 16, 2026
I'm hitting this issue as well. We have a client that parses and validates a JWT, which obviously fails on the placeholder.
The alias functionality helps in some cases, but it gets tricky/breaks down when key metadata is actually validated (e.g. JWT payload claims).
@derekwaynecarr thoughts on how OpenShell could support in the future? Potential workarounds?
cc @johntmyers @jmabry