Intermittent 20008 on explicit Bot field reads; token versus API failure stage is unavailable

Summary

On macOS (Apple Silicon), an authenticated lark-cli api GET request for Base field definitions intermittently exits with 20008: The user does not exist. while explicitly using a Bot identity. The same CLI version, selected app/profile, Base/table and request can succeed on a later invocation without a configuration change.

We reproduced the symptom with the released v1.0.93 binary. We have not established whether the error originates during tenant access-token acquisition, the subsequent Base API request, or another upstream condition; this report does not assert that the Base fields endpoint or the CLI itself is necessarily the root cause.

Request shape

With an already configured app profile and an authorized development Base/table:

lark-cli api GET /open-apis/bitable/v1/apps/APP_TOKEN/tables/TABLE_ID/fields \
  --as bot --format json --params '{"page_size":100}' --profile PROFILE

The identifiers above are placeholders. No business writes are involved. This is intermittent, not a deterministic reproduction recipe.

Observed behavior

The failure envelope contains:

{"ok":false,"identity":"bot","error":{"type":"api","subtype":"unknown","code":20008,"message":"The user does not exist."}}

• We observed this on more than one unchanged development read. A separate auth status --json --verify --profile PROFILE call and tenant-identity verification can succeed before a later field-read command fails.
• A direct failed field-read invocation completed in 871 ms. No request/log ID was present in the returned envelope.
• Successful field reads returned the expected field definitions. A fresh CLI process is used for each invocation, so successful auth status in another process does not prove token acquisition succeeded in the failed process.

Version comparison and diagnostic limits

A bounded comparison of the official v1.0.93 and v1.0.94 binaries used identical read arguments and environment, in old/new/new/old order. Both versions succeeded twice (about 1.2 seconds per call) and returned identical normalized field definitions. Remote metadata refresh and update/skill notifications were disabled for both versions in that comparison. This does not demonstrate a fix in v1.0.94 or establish either version's long-term failure rate.

A temporary diagnostic build based on tag v1.0.93 added only constant token-resolution success/failure markers to DoSDKRequest, without logging credentials, headers, resource IDs or response bodies. All five diagnostic calls succeeded, so we have not captured the failing stage. Compiler/build metadata differ from the distributed binary; those successful calls are not treated as proof of repair.

Inspection of v1.0.93/v1.0.94 found no registered --log-level/--debug/--verbose flag, and SDK logging is configured at Error level. The --log-level debug text in errs/ERROR_CONTRACT.md appears to be an illustrative hint rather than an implemented flag.

Questions / expected diagnostics

1. Is intermittent 20008 for an explicit Bot raw read a known issue in token acquisition or the upstream API?
2. Is there a supported way to distinguish token-resolution failure from API-response failure and obtain an available request/log ID without exposing secrets?
3. Could the structured error preserve the failing stage, and could the documented debug hint be aligned with the available CLI options?

We plan a conservative downstream workaround that retries this specific code only for already authorized semantic reads, with finite attempts, a time budget and retained diagnostics. We are not retrying uncertain writes or treating the error as permission to change identities.

Start at DoSDKRequest, the entry point named in the diagnostic build, and compare its token-resolution path with the api GET and auth status commands. Read errs/ERROR_CONTRACT.md to check the documented debug hint against available CLI options. Done should provide a supported, secret-safe way to distinguish token failures from API failures and preserve available request diagnostics.