pre_tool_snapshot did not respect config snapshots.enabled=false

[LmeSzinc]

Description

I have snapsnots disabled in ~/.codewhale/config.toml

[snapshots]
enabled = false
max_age_days = 7

but found my entire git repo was copied to ~/.deepseek/snapshots/a7cc237dcc939c78/a7cc237dcc939c78/.git which takes up GBs of disk space.

Root case (AI generated)

There are three snapshot call sites in the engine, but only two respect snapshots_enabled:

Snapshot call	Gated by enabled?	File:Line
pre_turn_snapshot	✅ Yes	crates/tui/src/core/engine.rs:979
post_turn_snapshot	✅ Yes	crates/tui/src/core/engine.rs:2120
pre_tool_snapshot	❌ No	crates/tui/src/core/engine/turn_loop.rs:2082

Steps to reproduce

1. Set [snapshots] enabled = false in ~/.codewhale/config.toml (or ~/.deepseek/config.toml).

2. Start codewhale, send a message that triggers file writes.

3. Check the snapshot directory — new tool:call_* git commits are still created.

   # e.g. on Linux/macOS
   cd ~/.deepseek/snapshots/*/*
   git log --oneline | head -5

   Expected: no snapshots at all.
   Actual: tool:call_* commits continue to appear.

Expected behavior

Actual behavior

Impact

Environment

• OS:
• codewhale version: 0.8.60
• Install method:
• codewhale doctor summary:
• Model/provider:
• Terminal app:
• Shell:

Logs, screenshots, or recordings

[github-actions]

Thanks @LmeSzinc for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.