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

首先追踪 issues #112、#538 和 #689 中引用的占位凭据模型及 L7 凭据注入工作，然后查看 docs/sandboxes/manage-providers.mdx。在 @slack/web-api 和 @slack/socket-mode 中复现网络前验证行为；完成的实现应解决这些初始化失败，同时保留文档中规定的不变量：sandbox 进程永远不会看到真实的凭据值。

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 #112
• L7 credential injection was generalized in #538 and #689
• OpenShell provider docs state: "The agent process inside the sandbox never sees real credential values" — this invariant is the root of the conflict