openclacky 0.7.3 → 0.7.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 7412866b05ae167fe6425d335db66e045a5e46ee02f20c25df41ff025c34d504
-  data.tar.gz: af3fb00041f896a6b9a8e98d7cb94be58ad49333e111cd6929233cedce684a80
+  metadata.gz: d4cbc9f7d1de1e64b78bd09ac59e9d911d101ab4e5e4bc6a2e869810311fffbc
+  data.tar.gz: 26de964a5a19c4eacf6a2fecff08dd6fe0dcdcc5baacb435fd53ed30095860cb
 SHA512:
-  metadata.gz: 97b3549db52c0f6f8f2b1b5f54f703b45e1aa8619a26909db5bd394bb8dd371972ddce81f61ed2a6047a7105a31be5eeb5e34a7fd1619e57107b363ce805de54
-  data.tar.gz: 231fe7e3e095fde2e295dc10d151f231532f44f541c3b623bc9e0efcee054f7a5e32ea58b6734ee6cc0f7e4b137b88d269c1a8a31ac3d6ebcd5c72ee21cd2438
+  metadata.gz: fdefc255c000713dc69b8062ce8a1e249fbbfe219716dcae1bc16c2ad32a5672080216172f63b4648f30680f9b4295e8cd3a717d0f7d05fc17f93922cc35227e
+  data.tar.gz: e650a5ef793d1c435ab23436f407bfff1a76def00a6047c0d6e75fbc13e41dcc5bc3b5ec538b6eef39a928d4dc5339c1c5b3f69da242b12b2fe8d4c59e51e381

data/.clacky/skills/commit/SKILL.md

@@ -9,14 +9,14 @@ user-invocable: true
 
 This skill helps users create well-structured, semantic git commits by analyzing changes and suggesting appropriate commit messages.
 
-## ⚠️ CRITICAL REQUIREMENT: SINGLE-LINE COMMITS ONLY
+## CRITICAL REQUIREMENT: SINGLE-LINE COMMITS ONLY
 
 **ALL commit messages created by this skill MUST be single-line only.**
 
-- ✅ DO: `git commit -m "feat: add user authentication"`
-- ❌ DON'T: Multi-line commits with body text
-- ❌ DON'T: Multiple `-m` flags
-- ❌ DON'T: Commit messages with `\n` or additional paragraphs
+- DO: `git commit -m "feat: add user authentication"`
+- DON'T: Multi-line commits with body text
+- DON'T: Multiple `-m` flags
+- DON'T: Commit messages with `\n` or additional paragraphs
 
 Keep commits concise and focused. If more detail is needed, suggest adding it separately in PR descriptions or documentation.
 
@@ -24,6 +24,19 @@ Keep commits concise and focused. If more detail is needed, suggest adding it se
 
 This skill automates the process of reviewing git changes and creating meaningful, conventional commits following the semantic commit format (feat/fix/chore/test).
 
+## Core Philosophy
+
+**THINK IN PURPOSES, NOT FILES**
+
+This skill prioritizes understanding the OVERALL GOAL of changes before deciding how to commit them. The default approach is to:
+1. Understand what the developer is trying to achieve
+2. Group all related changes into meaningful, purpose-driven commits
+3. Prefer fewer, cohesive commits over many fragmented ones
+
+DO NOT commit file-by-file. DO NOT separate tests from implementation. DO NOT fragment features across multiple commits.
+
+Instead, ask: "What story do these changes tell?" and commit accordingly.
+
 ## Usage
 
 To use this skill, simply say:
@@ -46,20 +59,124 @@ git status
 git diff --stat
 ```
 
-### 2. Review Changes in Detail
+### 2. HOLISTIC ANALYSIS - Understand the Overall Purpose
+
+CRITICAL: Before diving into file-by-file analysis, step back and ask:
+
+- What is the developer trying to achieve overall? (e.g., "Add authentication feature", "Fix login bugs", "Refactor database layer")
+- Is there a common theme or goal across these changes?
+- Can multiple changes be explained by a single higher-level purpose?
+
+Think strategically, not tactically:
+- BAD: "Changed auth.rb, changed user.rb, changed session.rb" -> 3 separate commits
+- GOOD: "These are all part of implementing user authentication" -> 1 commit
+
+Review ALL changes together first:
+```bash
+# Get overview of all changes
+git diff --stat
+git diff
+```
 
-For each changed file, analyze:
+Look for patterns:
+- Do multiple files serve the same feature?
+- Are there related bug fixes across files?
+- Is there a refactoring that touches multiple files?
+- Are tests accompanying their implementation?
+
+### 3. Review Changes in Detail
+
+Now examine each file to understand specifics:
 - The nature of changes (new feature, bug fix, refactoring, tests, documentation)
-- Scope of changes (which component/module)
-- Impact level (minor tweak vs major change)
+- How it connects to the overall purpose identified in step 2
+- Whether it's part of the main change or a separate concern
 
 ```bash
 git diff <file>
 ```
 
-### 3. Generate Commit Messages
+### 4. INTELLIGENT GROUPING - Merge Similar Changes
+
+CRITICAL PRINCIPLE: Prefer fewer, meaningful commits over many small commits
+
+**Grouping Strategy:**
+
+1. **Same Feature/Purpose = One Commit**
+   - All files contributing to the same feature should be in ONE commit
+   - Tests for a feature belong with the feature implementation
+   - Related configuration changes belong with the feature
+
+2. **Ask: "Would I explain these separately in a code review?"**
+   - If you'd say "I added X, Y, and Z as part of feature F" -> ONE commit
+   - If you'd say "I added X, and separately I fixed Y" -> TWO commits
 
-Based on the analysis, generate commit messages following the conventional commit format:
+3. **Look for these grouping opportunities:**
+   - Feature + Tests: Always together
+   - Implementation across multiple files: One commit if same feature
+   - Bug fix + Test: Together if addressing same issue
+   - Refactoring across modules: One commit if same refactoring goal
+   - Documentation + Code: Together if documenting the same change
+   - Configuration + Code: Together if config is required for the code
+
+4. **Only split when:**
+   - Changes serve genuinely different purposes
+   - Mixing would make the commit unclear or too broad
+   - One change is risky and should be isolated
+   - Different semantic types that shouldn't mix (feat vs fix vs chore)
+
+**Examples of Good Grouping:**
+
+GOOD - Merged into ONE commit:
+```
+Commit: feat: add user authentication
+  - lib/auth/authenticator.rb (new authentication logic)
+  - lib/user.rb (user model updates)
+  - lib/session.rb (session management)
+  - spec/auth/authenticator_spec.rb (tests)
+  - spec/user_spec.rb (updated tests)
+  - config/routes.rb (auth routes)
+```
+
+GOOD - Different purposes, TWO commits:
+```
+Commit 1: feat: add user authentication
+  - lib/auth/authenticator.rb
+  - spec/auth/authenticator_spec.rb
+  
+Commit 2: fix: resolve database timeout issue
+  - lib/database/connection.rb
+  - spec/database/connection_spec.rb
+```
+
+BAD - Over-splitting, should be ONE commit:
+```
+Commit 1: feat: add authentication logic
+  - lib/auth/authenticator.rb
+  
+Commit 2: feat: update user model for authentication
+  - lib/user.rb
+  
+Commit 3: test: add authentication tests
+  - spec/auth/authenticator_spec.rb
+  
+Commit 4: chore: add authentication routes
+  - config/routes.rb
+```
+
+**Decision Tree:**
+```
+Are changes related to the same goal/feature/purpose?
+|-- YES -> Combine into ONE commit
+|   +-- Even if they touch different files/modules
++-- NO -> Keep as separate commits
+    +-- Ask: Are they different semantic types (feat/fix/chore)?
+        |-- YES -> Definitely separate
+        +-- NO -> Consider if they could still be combined
+```
+
+### 5. Generate Commit Messages
+
+Based on the holistic analysis, generate commit messages following the conventional commit format:
 
 **Format**: `<type>: <description>`
 
@@ -67,8 +184,8 @@ Based on the analysis, generate commit messages following the conventional commi
 - `feat`: New features or functionality
 - `fix`: Bug fixes
 - `chore`: Routine tasks, maintenance, dependencies
-- `test`: Adding or modifying tests
-- `docs`: Documentation changes
+- `test`: Adding or modifying tests (only if standalone)
+- `docs`: Documentation changes (only if standalone)
 - `refactor`: Code refactoring without changing functionality
 - `style`: Code style changes (formatting, whitespace)
 - `perf`: Performance improvements
@@ -79,46 +196,53 @@ Based on the analysis, generate commit messages following the conventional commi
 - Use imperative mood ("add feature" not "added feature")
 - Don't end with a period
 - Be specific but brief
-- One logical change per commit
+- **One logical PURPOSE per commit** (not one file per commit)
+- Describe the overall goal, not implementation details
 - If more detail is needed, suggest adding it in PR description or commit body separately, but the initial commit MUST be single-line
 
 **Examples**:
-- `feat: add user authentication`
-- `fix: resolve memory leak in parser`
-- `chore: update dependencies`
-- `test: add unit tests for validator`
-- `docs: update README installation steps`
-
-### 4. Group Changes
+- `feat: add user authentication` (not "add authenticator.rb, user.rb, session.rb")
+- `fix: resolve login timeout issues` (not "fix auth.rb timeout")
+- `chore: update dependencies` (not separate commits for each gem)
+- `refactor: simplify database connection logic` (not one commit per file)
+- `docs: update API documentation` (only if pure documentation change)
 
-Organize changes into logical commits:
-- Group related changes together
-- Separate features, fixes, and chores
-- Keep commits atomic and focused
-- Suggest the order of commits
-
-### 5. Present Suggestions
+### 6. Present Suggestions
 
 Show the user:
-- List of proposed commits
+- **The overall purpose/goal you identified**
+- List of proposed commits (prefer fewer, consolidated commits)
 - Files included in each commit
 - Commit message for each group
-- Brief explanation of the grouping logic
+- **Brief explanation of WHY changes were grouped this way**
 
 Format:
 ```
-Commit 1: feat: add login endpoint
-  - lib/api/auth.rb
-  - spec/api/auth_spec.rb
-
-Commit 2: fix: resolve timeout in database connection
+Overall goal: Implementing user authentication system
+
+Proposed commits:
+
+Commit 1: feat: add user authentication
+  - lib/api/auth.rb (authentication logic)
+  - lib/user.rb (user model updates)
+  - lib/session.rb (session management)
+  - spec/api/auth_spec.rb (tests)
+  - spec/user_spec.rb (updated user tests)
+  - config/routes.rb (auth routes)
+  
+  Reason: All these files work together to implement the authentication
+  feature. Tests and configuration belong with the implementation.
+
+Commit 2: fix: resolve database timeout issue
   - lib/database/connection.rb
+  - spec/database/connection_spec.rb
+  
+  Reason: Separate bug fix unrelated to authentication.
 
-Commit 3: chore: update rubocop configuration
-  - .rubocop.yml
+Total: 2 commits (not 6+ small commits)
 ```
 
-### 6. Get User Confirmation
+### 7. Get User Confirmation
 
 Ask the user:
 - Review the proposed commits
@@ -126,7 +250,7 @@ Ask the user:
 - Allow modifications if needed
 - Get explicit approval before committing
 
-### 7. Execute Commits
+### 8. Execute Commits
 
 For each approved commit:
 ```bash
@@ -148,7 +272,7 @@ Provide feedback after each commit:
 - Show commit hash
 - Display summary
 
-### 8. Final Summary
+### 9. Final Summary
 
 After all commits:
 - Show total number of commits created
@@ -174,8 +298,8 @@ git add <file>
 git commit -m "type: single line description"
 
 # NEVER use multi-line format like:
-# git commit -m "title" -m "body"  ❌ DON'T DO THIS
-# git commit -m "title\n\nbody"    ❌ DON'T DO THIS
+# git commit -m "title" -m "body"  -- DON'T DO THIS
+# git commit -m "title\n\nbody"    -- DON'T DO THIS
 
 # View commit history
 git log --oneline -n 5
@@ -183,41 +307,77 @@ git log --oneline -n 5
 
 ## Workflow Example
 
+BAD Example (Over-splitting):
 ```
 User: /commit
 
-AI:
-1. Analyzing git status...
+AI (WRONG APPROACH):
+Found 5 modified files
+
+Proposed commits:
+  Commit 1: feat: add user model
+    - lib/user.rb
+  Commit 2: test: add user tests
+    - spec/user_spec.rb
+  Commit 3: fix: fix auth validation
+    - lib/auth.rb
+  Commit 4: test: add auth tests
+    - spec/auth_spec.rb
+  Commit 5: chore: update dependencies
+    - Gemfile
+
+Problem: Too fragmented! Tests separated from code.
+```
+
+GOOD Example (Holistic grouping):
+```
+User: /commit
+
+AI (CORRECT APPROACH):
+1. Analyzing all changes...
    Found 5 modified files
 
-2. Reviewing changes...
+2. Identifying overall purpose...
+   Main goal: Implementing user registration feature
+   Secondary: Fixing existing auth bug
+   Maintenance: Dependency updates
+
+3. Holistic analysis:
    - lib/user.rb: New user registration feature
-   - lib/auth.rb: Fix password validation bug
-   - spec/user_spec.rb: Tests for user registration
-   - spec/auth_spec.rb: Tests for auth fix
-   - Gemfile: Updated dependencies
+   - spec/user_spec.rb: Tests for user registration (same feature)
+   - lib/auth.rb: Fix password validation bug (separate concern)
+   - spec/auth_spec.rb: Tests for auth fix (same bug fix)
+   - Gemfile: Updated dependencies (separate maintenance)
 
-3. Proposed commits:
+4. Proposed commits (grouped by purpose):
 
    Commit 1: feat: add user registration
-     - lib/user.rb
-     - spec/user_spec.rb
+     - lib/user.rb (implementation)
+     - spec/user_spec.rb (tests)
+     
+     Reason: Feature and its tests belong together
 
    Commit 2: fix: correct password validation logic
-     - lib/auth.rb
-     - spec/auth_spec.rb
+     - lib/auth.rb (bug fix)
+     - spec/auth_spec.rb (tests)
+     
+     Reason: Fix and its tests belong together
 
    Commit 3: chore: update gem dependencies
      - Gemfile
+     
+     Reason: Unrelated maintenance task
 
-   Do you want to proceed with these commits? (yes/no)
+   Total: 3 meaningful commits instead of 5 fragmented ones
+
+   Do you want to proceed? (yes/no)
 
 User: yes
 
 AI:
-✓ Commit 1 created (a1b2c3d): feat: add user registration
-✓ Commit 2 created (e4f5g6h): fix: correct password validation logic
-✓ Commit 3 created (i7j8k9l): chore: update gem dependencies
+Commit 1 created (a1b2c3d): feat: add user registration
+Commit 2 created (e4f5g6h): fix: correct password validation logic
+Commit 3 created (i7j8k9l): chore: update gem dependencies
 
 Summary: 3 commits created successfully!
 Next steps: Review with 'git log' or push with 'git push'
@@ -233,22 +393,40 @@ Next steps: Review with 'git log' or push with 'git push'
 - Focus on "what" and "why", not "how"
 - Maximum 72 characters for the single line
 
-### Commit Organization
-- One logical change per commit
-- Keep features separate from fixes
-- Don't mix refactoring with new features
-- Test files go with their related code changes
-
-### When to Split Commits
-- Multiple unrelated features
-- Features and bug fixes mixed
-- Code changes and config changes
-- Different modules/components affected
-
-### When to Combine Changes
-- Related test and implementation
-- Multiple files for same feature
-- Complementary changes for same fix
+### Commit Organization - THINK PURPOSE, NOT FILES
+
+**GOLDEN RULE: One logical PURPOSE per commit, not one FILE per commit**
+
+### When to COMBINE Changes (Default Approach)
+- **Feature implementation + its tests** (ALWAYS together)
+- **Multiple files serving the same feature** (one commit)
+- **Bug fix + its test** (ALWAYS together)
+- **Code + required configuration** (together if config enables the code)
+- **Refactoring across multiple files** (one commit if same refactoring goal)
+- **Documentation + code it documents** (together if part of same change)
+- **Related files in same module/feature** (one commit)
+
+### When to SPLIT Commits (Exception Cases)
+- **Truly different purposes**: e.g., "add feature X" vs "fix bug Y"
+- **Different semantic types**: feat vs fix vs chore (usually)
+- **Risky changes**: isolate if one change is experimental
+- **Independent concerns**: changes that could be deployed separately
+- **Too broad scope**: if one commit does too many unrelated things
+
+### Anti-Patterns to Avoid
+- NEVER split implementation and tests into separate commits
+- NEVER create one commit per file unless files are truly independent
+- NEVER split configuration from the code that requires it
+- NEVER fragment a feature into multiple commits just because it touches multiple files
+
+### Decision Framework
+```
+For each set of changes, ask:
+1. "What was I trying to accomplish?" (identify the purpose)
+2. "Do these files work together toward that purpose?" (YES -> combine)
+3. "Would splitting these make the history harder to understand?" (YES -> combine)
+4. "Could these changes be deployed independently?" (NO -> combine)
+```
 
 ## Error Handling
 

data/CHANGELOG.md

@@ -7,6 +7,18 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [0.7.3] - 2026-02-26
+
+### Fixed
+- Modal component validation result handling after form submission
+- Modal height calculation for dynamic field count in form mode
+
+### Improved
+- Provider ordering prioritizes well-tested providers (OpenRouter, Minimax) first
+- Updated Minimax to use new base URL (api.minimaxi.com) and M2.5 as default
+- Updated model versions: Claude Sonnet 4.6, OpenRouter Sonnet 4-6, Haiku 4.5
+- Minimax model list now includes M2.1 and M2.5 (removed deprecated Text-01)
+
 ## [0.7.2] - 2026-02-26
 
 ### Added

data/bin/openclacky

@@ -1,6 +1,8 @@
 #!/usr/bin/env ruby
 # frozen_string_literal: true
 
+$LOAD_PATH.unshift File.expand_path("../lib", __dir__)
+
 require "clacky"
 
 Clacky::CLI.start(ARGV)

data/lib/clacky/agent/message_compressor_helper.rb

@@ -7,7 +7,7 @@ module Clacky
     module MessageCompressorHelper
       # Compression thresholds
       COMPRESSION_THRESHOLD = 150_000  # Trigger compression when exceeding this (in tokens)
-      MESSAGE_COUNT_THRESHOLD = 150   # Trigger compression when exceeding this (in message count)
+      MESSAGE_COUNT_THRESHOLD = 200   # Trigger compression when exceeding this (in message count)
       MAX_RECENT_MESSAGES = 20  # Keep this many recent message pairs intact
       TARGET_COMPRESSED_TOKENS = 10_000  # Target size after compression
       IDLE_COMPRESSION_THRESHOLD = 20_000  # Minimum messages needed for idle compression

data/lib/clacky/agent/system_prompt_builder.rb

@@ -24,14 +24,15 @@ module Clacky
            - After creating the TODO list, START EXECUTING each task immediately
            - Don't stop after planning - continue to work on the tasks!
         2. Always read existing code before making changes (use file_reader/glob/grep or invoke code-explorer skill)
-        3. Ask clarifying questions if requirements are unclear
-        4. Break down complex tasks into manageable steps
-        5. **USE TOOLS to create/modify files** - don't just return code
-        6. Write code that is secure, efficient, and easy to understand
-        7. Test your changes using the shell tool when appropriate
-        8. **IMPORTANT**: After completing each step, mark the TODO as completed and continue to the next one
-        9. Keep working until ALL TODOs are completed or you need user input
-        10. Provide brief explanations after completing actions
+        3. **Use glob tool to search for files** - it respects .gitignore, filters binary files, and sorts by modification time
+        4. Ask clarifying questions if requirements are unclear
+        5. Break down complex tasks into manageable steps
+        6. **USE TOOLS to create/modify files** - don't just return code
+        7. Write code that is secure, efficient, and easy to understand
+        8. Test your changes using the shell tool when appropriate
+        9. **IMPORTANT**: After completing each step, mark the TODO as completed and continue to the next one
+        10. Keep working until ALL TODOs are completed or you need user input
+        11. Provide brief explanations after completing actions
 
         IMPORTANT: You should frequently refer to the existing codebase. For unclear instructions,
         prioritize understanding the codebase first before answering or taking action.

data/lib/clacky/agent/tool_executor.rb

@@ -98,22 +98,12 @@ module Clacky
             preview_error = show_write_preview(args)
           when "edit"
             preview_error = show_edit_preview(args)
-          when "shell", "safe_shell"
-            show_shell_preview(args)
-          else
-            # For other tools, show formatted arguments
-            tool = @tool_registry.get(call[:name]) rescue nil
-            if tool
-              formatted = tool.format_call(args) rescue "#{call[:name]}(...)"
-              @ui&.show_tool_args(formatted)
-            else
-              @ui&.show_tool_args(call[:arguments])
-            end
+          # Shell and other tools don't need special preview
+          # They will be shown via show_tool_call in the main flow
           end
 
           preview_error
         rescue JSON::ParserError
-          @ui&.show_tool_args(call[:arguments])
           nil
         end
       end
@@ -256,7 +246,8 @@ module Clacky
             /go\s+(build|test)/,
             /make\s+(test|build)/,
             /pytest/,
-            /jest/
+            /jest/,
+            /sleep\s+\d+/  # sleep command with duration
           ]
 
           slow_patterns.any? { |pattern| command.match?(pattern) }

data/lib/clacky/agent.rb

@@ -458,16 +458,37 @@ module Clacky
             args[:skip_safety_check] = true
           end
 
-          # Show progress for potentially slow tools (no prefix newline)
-          if potentially_slow_tool?(call[:name], args)
+          # Automatic progress display after 2 seconds for any tool execution
+          progress_shown = false
+          progress_timer = nil
+          output_buffer = nil
+          
+          if @ui
             progress_message = build_tool_progress_message(call[:name], args)
-            @ui&.show_progress(progress_message, prefix_newline: false)
+            
+            # For shell commands, create shared output buffer
+            if call[:name] == "shell" || call[:name] == "safe_shell"
+              output_buffer = { content: "", timestamp: Time.now }
+              args[:output_buffer] = output_buffer
+            end
+            
+            progress_timer = Thread.new do
+              sleep 2
+              @ui.show_progress(progress_message, prefix_newline: false, output_buffer: output_buffer)
+              progress_shown = true
+            end
           end
 
-          result = tool.execute(**args)
-
-          # Clear progress if shown
-          @ui&.clear_progress if potentially_slow_tool?(call[:name], args)
+          begin
+            result = tool.execute(**args)
+          ensure
+            # Cancel timer and clear progress if shown
+            if progress_timer
+              progress_timer.kill
+              progress_timer.join
+            end
+            @ui&.clear_progress if progress_shown
+          end
 
           # Track modified files for Time Machine snapshots
           track_modified_files(call[:name], args)

data/lib/clacky/cli.rb

@@ -2,6 +2,7 @@
 
 require "thor"
 require "tty-prompt"
+require "fileutils"
 require_relative "ui2"
 require_relative "json_ui_controller"
 
@@ -224,7 +225,17 @@ module Clacky
       def validate_working_directory(path)
         working_dir = path || Dir.pwd
 
-        # Expand path to absolute path
+        # If no path specified and currently in home directory, use ~/clacky_workspace
+        if path.nil? && File.expand_path(working_dir) == File.expand_path(Dir.home)
+          working_dir = File.expand_path("~/clacky_workspace")
+          
+          # Create directory if it doesn't exist
+          unless Dir.exist?(working_dir)
+            FileUtils.mkdir_p(working_dir)
+          end
+        end
+        
+        # Always expand to absolute path
         working_dir = File.expand_path(working_dir)
 
         # Validate directory exists
@@ -424,6 +435,12 @@ module Clacky
 
       # Run agent with UI2 split-screen interface
       def run_agent_with_ui2(agent, working_dir, agent_config, session_manager = nil, client = nil, is_session_load: false)
+        # Detect terminal background BEFORE starting UI2 to avoid output interference
+        is_dark_bg = UI2::TerminalDetector.detect_dark_background
+        
+        # Pass detected background mode to theme manager (singleton)
+        UI2::ThemeManager.instance.set_background_mode(is_dark_bg)
+        
         # Validate theme
         theme_name = options[:theme] || "hacker"
         available_themes = UI2::ThemeManager.available_themes.map(&:to_s)
@@ -535,7 +552,7 @@ module Clacky
 
           # Cancel idle timer if running (new input means user is active)
           if idle_timer_thread&.alive?
-              ui_controller.log("Idle timer killed, start new 1", level: :debug)
+            # ui_controller.log("Idle timer killed, start new 1", level: :debug)
             idle_timer_thread.kill
             idle_timer_thread = nil
           end
@@ -544,17 +561,17 @@ module Clacky
           start_idle_timer = lambda do
             # Cancel any existing idle timer first
             if idle_timer_thread&.alive?
-              ui_controller.log("Idle timer killed, start new 2", level: :debug)
+              # ui_controller.log("Idle timer killed, start new 2", level: :debug)
               idle_timer_thread.kill
               idle_timer_thread = nil
             end
 
             # Start idle timer - trigger compression after 180 seconds of inactivity
             idle_timer_thread = Thread.new do
-              ui_controller.log("Idle timer started, will trigger compression in 180 seconds", level: :debug)
+              # ui_controller.log("Idle timer started, will trigger compression in 180 seconds", level: :debug)
               # Sleep outside of rescue block - if interrupted here, let it propagate and exit
               sleep 180
-              ui_controller.log("Idle timer sleep completed, starting compression", level: :debug)
+              # ui_controller.log("Idle timer sleep completed, starting compression", level: :debug)
 
               # After sleep completes, switch to current_task_thread for compression
               # (so it can be interrupted by Ctrl+C)