Credential placeholder model breaks SDKs that validate token format before making network calls

[jyaunches]

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