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

memtool on Windows can now reach process memory that the previous build was locked out of, in two ways. Both are Windows-only; Linux and macOS behavior is unchanged.

Feature: memtool auto-enables SeDebugPrivilege when elevated

Previously, running agent-tool as Administrator was not enough to open a process whose DACL had been hardened, or one running at a higher integrity level -- the open still failed with "Access is denied". The reason: bypassing a process object's DACL during OpenProcess requires the SeDebugPrivilege, and that privilege -- even though it is present in an elevated administrator token -- is disabled by default. The old code never enabled it, so an elevated memtool had no more reach than a normal one against a protected target.

memtool now enables SeDebugPrivilege on first process open, once per process lifetime (sync.Once). The implementation is best-effort and adjusts only memtool's own token:

• It opens the current process token, looks up the SeDebugPrivilege LUID, and calls AdjustTokenPrivileges to enable it.
• A standard (non-elevated) user token does not contain SeDebugPrivilege at all, so the call returns ERROR_NOT_ALL_ASSIGNED and is silently ignored -- there is no UAC prompt, no error, and no behavior change for non-admin users. Same-user, default-DACL targets keep working exactly as before.
• When agent-tool is elevated, the privilege is now actually active, so memtool can read DACL-hardened and higher-integrity processes that previously refused to open.

This does not defeat PPL (Protected Process Light) / anti-cheat protection -- that is enforced in the kernel and requires a driver, not a token privilege.

The access-denied error message was also rewritten to be actionable for an agent: it now distinguishes "run elevated to read DACL-protected / higher-integrity processes" from "the target is PPL/anti-cheat protected and cannot be read from user mode", instead of the old blanket "run as Administrator" that an agent would uselessly retry.

Feature: opt-in force_dacl -- read a same-user process behind a self-hardened DACL, without elevation

Some applications defend their memory not with PPL or a kernel driver, but by simply tightening their own process DACL at runtime (adding a deny ACE) so that even another process owned by the same user is refused PROCESS_VM_READ. SeDebugPrivilege only helps here when you are elevated. For the non-elevated, same-user case there is now an explicit, opt-in path:

memtool(operation="read", pid=1234, address="0x...", force_dacl=true)

How it works. Windows always grants the owner of a securable object an implicit READ_CONTROL + WRITE_DAC, regardless of the DACL (unless the object carries an OWNER_RIGHTS SID). A process object's owner is the user who launched it. So a same-user caller can rewrite the target's DACL even after being denied read access. When force_dacl=true and a normal open fails specifically with ERROR_ACCESS_DENIED, memtool:

1. Opens the target with WRITE_DAC | READ_CONTROL via that owner-implicit grant.
2. Saves the target's current DACL.
3. Temporarily replaces the DACL with a single ACE that grants only the current user the requested access. (It replaces rather than appends, because in canonical ACL order deny ACEs are evaluated before allow ACEs -- appending an allow would not override an existing deny. Granting only our own SID means no third party gains access during the brief window.)
4. Opens the memory handle. A handle's access rights are fixed at OpenProcess time, so the handle keeps working afterward.
5. Always restores the original DACL -- on every path, including failures.

Concurrent force_dacl opens against the same target are serialized with a global lock, so a second rewrite cannot snapshot the first's temporary grant DACL as the "original" and restore to that (a TOCTOU that would otherwise leave the target permanently open).

What it cannot do. force_dacl only helps for a same-user target that hardened its own DACL. It cannot bypass a higher-integrity process, a process owned by another user, a process carrying an OWNER_RIGHTS SID, or a PPL/anti-cheat process -- those are integrity/kernel boundaries, not DACL ones, and the bypass fails cleanly with a descriptive error, leaving the target untouched.

force_dacl defaults to false; the invasive DACL rewrite never happens unless you explicitly ask for it.

This release was verified end-to-end on Windows: a same-user target self-hardens its DACL (deny PROCESS_VM_READ), memtool is denied without force_dacl, succeeds with force_dacl=true, and is denied again afterward -- confirming the original DACL is restored.