[BUG] [v0.0.7] All cortex lock subcommands expose raw JSON parse error when session_locks.json is corrupt — no file path, no recovery hint

[Grizouforever]

Project

ide

Description

When the session lock file (~/.cortex/session_locks.json) is corrupt or manually edited with a typo, all lock subcommands (list, add, check, remove) fail with a raw serde JSON parse error that exposes internal implementation details and provides no actionable information to the user.

The error message is: "Error: key must be a string at line 1 column 16". This gives the user no indication that the problem is with the lock configuration file, no file path to investigate, and no suggestion on how to fix it (e.g., deleting the file to reset).

This can happen in practice when a write is interrupted (power loss, disk full) or when the user tries to manually edit the lock file to add notes or adjust entries.

Error Message

Error: key must be a string at line 1 column 16

Debug Logs

N/A

System Information

• Cortex TUI v0.0.7
• OS: Linux x86_64

Screenshots

Steps to Reproduce

1. Introduce a syntax error in the session lock file by manually editing it (e.g., remove quotes around a key)
2. Run cortex lock list
3. Observe the raw JSON parse error with no file path or recovery suggestion
4. Run cortex lock add "12345678" --reason "test" — same raw error
5. Run cortex lock check "12345678" — same raw error

Expected Behavior

When the lock file is corrupt, cortex should display a user-friendly error message that includes the file path and a recovery suggestion, such as: "Error: Failed to read session lock file (~/.cortex/session_locks.json): invalid JSON. Delete the file to reset your session locks."

Actual Behavior

All lock commands propagate the raw serde_json parse error ("key must be a string at line 1 column 16") without context about which file is affected or how to fix the problem. The user has no way to know which file is corrupt or how to recover.

[echobt]

The issue reports that when ~/.cortex/session_locks.json is corrupt, all cortex lock subcommands fail with a raw serde_json parse error (e.g., "Error: key must be a string at line 1 column 16") without providing the file path or a recovery hint.

I verified this in the codebase. In src/cortex-cli/src/lock_cmd.rs, the load_lock_file function reads and parses the JSON file:

fn load_lock_file() -> Result<LockFile> {
    let path = get_lock_file_path();

    if !path.exists() {
        return Ok(LockFile {
            version: 1,
            locked_sessions: Vec::new(),
        });
    }

    let content = std::fs::read_to_string(&path)?;
    let lock_file: LockFile = serde_json::from_str(&content)?;
    Ok(lock_file)
}

The ? operator on serde_json::from_str(&content)? propagates the raw serde_json::Error directly to the caller, which eventually gets printed to the user by anyhow. There is no context added to the error (like .with_context(|| format!("Failed to parse lock file at {:?}", path))), so the user only sees the raw JSON parsing error without knowing which file caused it or how to fix it.

The screenshot confirms this behavior, showing the raw error message when running cortex lock list, cortex lock add, and cortex lock check.

This is a valid bug as it exposes internal implementation details and provides a poor user experience when a configuration file is corrupted.