knewstimek/agent-tool

Quick Start

1. Download the binary for your OS below
2. Run agent-tool install (or agent-tool install claude)
3. Restart your IDE
4. Done -- all tools work immediately, no permission popups

Or just ask your AI agent:

"Download agent-tool from https://github.com/knewstimek/agent-tool/releases/latest and run agent-tool install"

Any capable AI coding agent (Claude Code, Codex, etc.) can handle the full download -> install -> restart flow automatically.

Tip: Add this to your CLAUDE.md or AGENTS.md so your agent prefers agent-tool over built-in tools:

Strict mode:

ALWAYS use agent-tool MCP tools (mcp__agent-tool__*) instead of built-in file tools. agent-tool preserves file encoding and respects .editorconfig indentation settings.

Soft mode:

Prefer agent-tool MCP tools (mcp__agent-tool__*) over built-in file tools when available.

What's New

Fix: wintool clipboard read no longer permanently breaks the system clipboard

Reading an image from the clipboard via wintool operation=clipboard could leave the Windows clipboard in a permanently stuck state -- after the call, no application could paste the existing image, and even fresh captures (Win+Shift+S, etc.) failed to register on the clipboard. The only known recovery was clearing the clipboard manually (e.g. cmd /c "echo off | clip") or killing the agent-tool process.

Root cause. GetClipboardData returns a system-cached / synthesized HGLOBAL whose internal lock count may already be >= 1 before the caller touches it. The previous code called GlobalLock(hGlobal) (+1) and GlobalUnlock(hGlobal) (-1) exactly once each. When the handle came in pre-locked, the single GlobalUnlock left the lock count at >= 1, so the system could not free the handle on the next EmptyClipboard / SetClipboardData -- which is exactly the API path used when another app tries to put new content on the clipboard. The result: the clipboard was effectively read-only until the agent-tool process exited.

Fix. A new fullyUnlock helper calls GlobalUnlock repeatedly until it returns 0 (per the winbase.h contract: 0 means "lock count reached 0", nonzero means "still locked after this call"). This drains the lock count to 0 regardless of whether the handle was returned pre-locked, so the system can free it normally. A safety cap of 32 iterations prevents pathological loops.

Hardening: clipboard owner hwnd and retry on lock contention

While investigating the stuck-clipboard issue, two additional weaknesses in the clipboard read path were addressed:

• Real owner hwnd instead of NULL. OpenClipboard(NULL) is associated with sticky owner state in some environments because owner transitions through EmptyClipboard go via a NULL hwnd (SetClipboardData then fails). The new code creates a process-wide message-only window (HWND_MESSAGE parent, "STATIC" class, lazily created on first use) and passes its hwnd to OpenClipboard. This is the same pattern used by .NET, Qt, and other Win32 clipboard libraries.
• Retry on transient lock contention. OpenClipboard is now retried at 100ms intervals up to 10 times, matching the default behavior of Clipboard.SetDataObject on .NET. The clipboard is a single serialized resource and brief contention with other processes is normal.

Hardening: minimal clipboard hold time

The clipboard is now released (explicit GlobalUnlock + CloseClipboard) immediately after the pixel data is decoded into an in-memory image. PNG encoding and file writing -- which can take tens of milliseconds for typical screenshots -- now run after the clipboard is closed, so other processes are no longer blocked from reading or writing the clipboard during the encode step.

Full Changelog: https://github.com/knewstimek/agent-tool/compare/v0.8.5...v0.8.6