Security/UX: Config desynchronization between Wrapper and CLI (Wallet Mismatch Risk)

[maddefientist]

The Issue

A critical desynchronization can occur where the external wrapper (Clawdbot/MCP) expects one wallet/private key based on its environment variables/config, but the underlying slopesniper CLI continues to use a cached or differently configured wallet stored in ~/.slopesniper.

Risk to User

• Financial Risk: Users may believe they are trading on one wallet while the system is executing trades on an 'old' or different wallet (e.g., one generated during a previous setup).
• Confusion/Opacity: The user cannot easily see why the 'current' wallet isn't changing despite updating the wrapper's environment variables.
• Security: If the CLI falls back to a bundled or improperly cleared key after an update (as seen with the 401 errors), it creates a state of system instability.

Observed Behavior

1. Clawdbot config was updated with a new apiKey (private key).
2. slopesniper status and slopesniper wallet continued to report the old address.
3. The CLI reported 401 Unauthorized errors even after the wrapper was 'corrected', suggesting the CLI's internal state (config.enc / config.db) was stale or mismatched with the expected API format of the new version.

Potential Fixes / Outcomes

1. Sync Check on Startup: The CLI should provide a way to verify if the current environment's SOLANA_PRIVATE_KEY matches the active wallet in its internal DB.
2. Explicit Override: If a private key is passed via environment or flag, the CLI should prioritize it or automatically trigger an import-sync if it differs from the internal cache.
3. Improved Error Feedback: Clearer messaging when the Jupiter API key (bundled vs. user-provided) fails, specifically indicating if it's a version-related config change.
4. Health Command: A dedicated command to verify the integrity and 'sync state' of the local database vs. the current environment.

Note

This was identified during a live session where a user switched wallets, but the CLI was 'stuck' on an older deployment's state.