auth status --verify fails in macOS automation context: keychain Get failed: keychain not initialized

[Moskize91]

Summary

lark-cli --profile <profile> auth status --verify works in an interactive desktop session, but fails consistently in an automation/background context on macOS with:

keychain Get failed: keychain not initialized

This blocks any later Feishu doc/wiki operations before network/API access is even attempted.

Version

lark-cli version 1.0.38

Environment

• macOS
• lark-cli installed from npm
• profile already configured and valid in interactive use
• same machine, same user account
• failure happens specifically in a recurring automation / background execution context

Reproduction

1. Configure a normal user profile, for example:

   lark-cli --profile oomol auth status --verify

2. Run the same command in a foreground interactive terminal session.
3. Run the same command from an automation/background context on the same machine and same user account.

Expected behavior

If the profile and token are valid, auth status --verify should either:

• succeed in the background context, or
• return a more precise error that clearly explains the required macOS/session precondition.

Actual behavior

In the background/automation context, the command fails repeatedly with:

{
  "ok": false,
  "error": {
    "type": "config",
    "message": "keychain Get failed: keychain not initialized"
  }
}

We retried the exact same command 3 times in the same automation run and got the same error all 3 times.

Important observations

• The same profile succeeded earlier on the same day in an interactive context.
• LARK_PROFILE was not misconfigured.
• This does not fail at Feishu doc/wiki read/write time.
• This does not fail at webhook/message send time.
• The failure occurs before any Feishu API call, while lark-cli is reading local credentials / keychain state.

Why this seems like a real bug / compatibility gap

From the changelog it looks like the project has already improved sandbox / keychain handling for agent environments. However, on 1.0.38, a real macOS automation context can still reliably reproduce this failure.

This is especially problematic for users who rely on lark-cli inside local recurring automations, agent runners, or other non-foreground execution contexts.

Suggested direction

Any of the following would help:

• document the exact macOS session requirements for auth status --verify
• provide a supported non-keychain credential mode for automation contexts
• improve detection and recovery for background/session-limited execution
• clarify whether this scenario is unsupported by design

Thanks.