AutoHotkey v2 — Console Fork

A build of AutoHotkey v2.1-alpha that behaves like a real command-line program: runtime errors go to stderr (as text or JSON), failures return meaningful exit codes, dialogs can be suppressed, and the debugger speaks DBGp so an LLM can drive it. Everything else is stock AutoHotkey.

Docs site: truecrimedev.github.io/AutoHotkey — Console engine guides plus the ClautoHotkey harness (static and dry-run gates for Claude Code).

---

Contents

• Why this fork
• Quick start
• Running scripts
• Error reporting
• Exit codes
• Language additions
• Native JSON and local tools
• REPL
• Crash logging
• Line coverage
• Inspecting live objects
• Driving child processes
• CI for AutoHotkey libraries
• AI-assisted debugging
• Repository map
• Documentation
• License

---

Why this fork

Stock AutoHotkey is built for the desktop: errors open a MsgBox, output goes to GUIs, and a script that fails still exits 0. That model fights you the moment you run scripts from a terminal, a CI job, or an agent loop. This fork keeps the language identical and changes only the plumbing around it so AHK fits into pipes, scripts, and tooling.

	Stock AutoHotkey	This fork
Runtime error	Modal MsgBox; nothing on stderr	Formatted text on stderr, with source context and stack
Machine-readable errors	—	/Diag=json emits a one-line JSON diagnostic per error
Exit code on failure	0	Distinct non-zero codes per failure class (10–14, 64, 130)
Unattended runs	Dialogs block forever	/Headless suppresses the engine's own prompts (script MsgBox calls still show)
Syntax checking	Run it and see	check subcommand: parse-only, exit 0/13
Single-script tests	Roll your own	test subcommand: exit 0 on pass; failures keep their codes (test exit codes)
Crash forensics	Lost when the window closes	/CrashLog= append-only event log that survives hard crashes
Inline evaluation	—	Eval("expr") runs an expression in live scope (opt-in)
Interactive session	—	repl subcommand: persistent eval loop over stdin/stdout
stdout helper	FileOpen("*","w") boilerplate	Print(fmt, args*) — UTF-8, Format-aware
Debugger	DBGp (desktop-oriented)	Same DBGp, wired to an MCP server for LLM-driven debugging

None of this touches the language. The engine is upstream v2.1-alpha.37 (see docs/alpha/v2.1-alpha.37.md), so scripts that run on that upstream code run here unchanged; the additions are flags, subcommands, and a few opt-in built-ins.

---

Quick start

Build (Windows)

CMake is the supported build route. BUILD.md has the prerequisites and commands for MSVC x64, MSVC Win32, and mingw-w64 GCC x64 (the three configurations CI builds, syntax-checks and gates), and how to verify the exact executable you built. The two x64 routes produce the console engine AutoHotkey64Console.exe, which the examples in this README use, and the GUI AutoHotkey64.exe; the Win32 route produces AutoHotkey32Console.exe and AutoHotkey32.exe.

• Output directory. CMake's AHK_OUTPUT_DIR defaults to bin\. BUILD.md's commands pass isolated directories (out\msvc\x64, out\mingw\x64) so a build never overwrites the engine in bin\. Copy a tested build into bin\ when you want the examples below, tools/ahk.ps1, and the Claude Code setup (.mcp.json, hooks) to use it.
• build.bat is a convenience wrapper for the mingw-w64 route: it builds in build_gcc\ and writes both executables straight into bin\.
• AutoHotkeyx.sln / build_local.bat remain available for the GUI executable only.

First run

bin\AutoHotkey64Console.exe script.ahk

Use bin\AutoHotkey64Console.exe --help to discover commands, --version to identify the engine, compiler, architecture, and source revision, or --capabilities for JSON. An uncommitted source build reports its base revision with a -dirty suffix.

For PowerShell, build AutoHotkey64Console as described in BUILD.md and dot-source tools/ahk.ps1 from this checkout (or from your PowerShell profile). It registers ahk as a native alias to bin/AutoHotkey64Console.exe, so the terminal waits for scripts and the REPL receives keyboard input directly.

. .\tools\ahk.ps1
ahk                       # Version and quick guide
ahk help                  # Also: -h, --h, -help, --help
ahk run .\script.ahk       # Or: ahk .\script.ahk
ahk check .\script.ahk
ahk repl                  # Type .exit to return to PowerShell

The console executable reports script errors in the terminal by default. The standard AutoHotkey64.exe remains available for GUI launches; PowerShell does not wait for it unless its output is piped, so its exit code is lost. See the PowerShell repair notes for troubleshooting.

Git tracks only bin/tree-sitter-ahk.dll; everything else in bin/ is local, so a fresh clone has no engine there until you build one or copy a release console engine in. Executables in bin/ can also be older than the source, and the x64 and x86 or GUI and console files need not come from the same build, so check --version on the one you run. For everyday terminal use, choose AutoHotkey64Console.exe through ahk.

Confirm the console behavior

bin\AutoHotkey64Console.exe tests\test_console.ahk 1>out.txt 2>err.txt

Normal output ends up in out.txt; the runtime error lands in err.txt, and the process exits 10. That split — stdout for results, stderr for diagnostics — is the whole point.

---

Running scripts

One executable, selected into different modes by its first arguments:

Invocation	Mode
AutoHotkey64Console.exe script.ahk	Normal run; runtime errors → stderr as text
AutoHotkey64Console.exe /Debug script.ahk	Connect to a DBGp debugger (default localhost:9000; /Debug=host:port for another). With no listener, or when it goes away, the script runs on and stderr says Debugger error: ... continuing without the debugger.
AutoHotkey64Console.exe /ErrorStdOut script.ahk	Runtime errors → stderr as text (the console engine's default)
AutoHotkey64Console.exe /ErrorStdOut:color script.ahk	…with ANSI color
AutoHotkey64Console.exe /ErrorStdOut=UTF-8 script.ahk	…with an explicit encoding
AutoHotkey64Console.exe /Headless script.ahk	Report the engine's error and warning prompts on stderr instead of dialogs (a script's own MsgBox, InputBox, and Gui still show)
AutoHotkey64Console.exe /Diag=json script.ahk	Runtime errors → stderr as JSON
AutoHotkey64Console.exe check script.ahk	Parse only — exit 0 (ok) / 13 (fail)
AutoHotkey64Console.exe test script.ahk	Run as a test — exit 0 (pass), 10 (uncaught error), 12 (parse error), 14 (ExitApp(14), a persistent script, or an execution failure)
AutoHotkey64Console.exe repl [script.ahk]	Interactive / pipe-driven eval session (REPL)
AutoHotkey64Console.exe mcp	Native local tools over stdin/stdout
AutoHotkey64Console.exe --help	Commands, flags, and usage
AutoHotkey64Console.exe --version	Engine version and build identity
AutoHotkey64Console.exe --capabilities

The GUI AutoHotkey64.exe accepts the same commands and flags; use the console engine from a terminal, CI job, or agent so the shell waits for it and receives its output.

Flags compose. A typical unattended invocation:

bin\AutoHotkey64Console.exe /Headless /Diag=json script.ahk 2>diagnostics.jsonl

Global flags can precede a command: /Headless /Diag=json check script.ahk. Arguments after the script filename belong to the script. Use -- before a script filename which would otherwise be interpreted as a command or flag.

--help lists every spelling the parser accepts, with its value syntax. The same list:

Option	Effect
/Headless, --headless	Report the engine's prompts on stderr instead of dialogs
/Diag[=text|json], --diag[=text|json]	Diagnostic format on stderr (default text)
/ErrorStdOut[=encoding]	Diagnostic text encoding: UTF-8, UTF-16, CPnnn or nnn
/ErrorStdOut:color|nocolor	Force ANSI color on or off (nocolor also none, off)
/Trace[=text|json], --trace[=text|json]	Stream executing statements to stderr (json: one event per line)
/Eval, --eval	Enable Eval() in the script
/Debug[=host[:port]|stdio]	Connect to a DBGp debugger (default localhost:9000); stdio speaks DBGp over stdin/stdout
/CrashLog=path, --crashlog=path	Append crash and process lifecycle events (Crash logging)
/StdErrFile=path, --stderrfile=path	Mirror diagnostics to a file
/Coverage=path, --coverage=path	Write LCOV line coverage at exit (Line coverage)
/include file	Include one file before the script (at most once)
/CPnnn	Script source code page
/force	Replace an existing instance of the script
/restart	Mark the launch as a restart (Reload uses it): an existing instance is closed instead of prompting

Git Bash rewrites any argument that starts with / into a path, so from Git Bash use the -- aliases above, or double the slash for a switch without one (//Debug, //ErrorStdOut, //include). PowerShell and cmd pass /Flag unchanged.

---

Error reporting

Human-readable (/ErrorStdOut)

A runtime error is printed to stderr with the location, the message, and a source window that marks the offending line:

demo.ahk (4) : ==> This value of type "String" has no method named "NoSuchMethod".
          2| Print("starting work")
          3| x := "hello"
        > 4| x.NoSuchMethod()
          5|
          6|

The process exits 10, so a shell or CI step sees the failure without parsing anything.

Machine-readable (/Diag=json)

The same error, as one JSON object per line (newline-delimited — pipe it straight into a .jsonl consumer):

{"kind":"diagnostic","format":"json","schema":2,"severity":"error","type":"MethodError","code":10,"message":"This value of type \"String\" has no method named \"NoSuchMethod\".","extra":"","what":"","file":"demo.ahk","line":4,"column":0,"source":"x.NoSuchMethod()","stack":""}

Fields (schema 2):

Field	Meaning
kind	"diagnostic" (errors/warnings) or "check" (the check subcommand verdict)
severity	error or warning
type	AHK error class — MethodError, TypeError, ValueError, …
code	The process exit code this error maps to
message	The error text
file, line, column	Location (column is best-effort; often 0)
source	The exact source line
what, extra, stack	Function context, extra detail, and call stack when available

#Warn diagnostics flow through the same formatter, so a warning becomes a "severity":"warning" record instead of corrupting stdout. The check subcommand emits {"kind":"check","status":"pass"} on success.

Stream separation

FileAppend("result`n", "*")    ; → stdout
FileAppend("oops`n", "**")     ; → stderr

Results and diagnostics stay on separate streams, so a consumer can read 1> and 2> independently.

---

Exit codes

Failures are distinguishable by exit code alone — no output scraping required:

Code	Meaning	Crash-log reason
0	Success	Normal
10	Uncaught script exception	Error
11	Internal/critical error or SEH fault	Critical / Fatal
12	Parse / load failure	Parse
13	check failed	Check
14	test failed	Test
64	CLI usage error	Usage
130	Ctrl+C / console close / logoff / shutdown	ExternalSignal

ExitApp(n) with any other n passes that code straight through.

Under test, a script that runs to its end exits 0 and prints TEST PASS. An uncaught error still exits 10 and a parse error 12. Code 14 comes from an explicit ExitApp(14) (the Test.ahk framework uses it for failed cases), a persistent script (TEST FAIL: test mode requires a non-persistent script.), or an execution failure. Other ExitApp(n) codes pass through, 0 included, without the TEST PASS line. --capabilities lists the codes under exitCodes.

---

Language additions

A small set of fork-only built-ins. The first two are always available; Eval is opt-in. See updates.md for the complete reference, edge cases, and tests.

Print(fmt, args*) — stdout, the easy way

UTF-8 println with built-in Format dispatch. No FileOpen boilerplate; a silent no-op when no console is attached.

Print("hello")                      ; hello
Print("x={}, y={}", 42, "world")    ; x=42, y=world
Print("0x{:08X}", 0xDEAD)           ; 0x0000DEAD
Print("{ok: true}")                 ; single-arg form is literal — braces survive

Eval(expr) — evaluate an expression in live scope (opt-in)

Runs any AHK expression string against the caller's variables — reads and writes locals, calls methods, supports v2.1-alpha expression features (maybe operator, unset propagation). Gated behind #EnableEval (or the /Eval flag) so it can never run unless you ask for it.

#EnableEval
x := 10, y := 20
MsgBox(Eval("x + y"))   ; 30
Eval("x := x + 1")      ; mutates the caller's x

Bad input throws SyntaxError; missing identifiers throw UnsetError.

SyntaxError — parse-failure exception

An Error subclass, thrown by Eval on parse failure and available for your own parsers to throw. One thrown by Eval carries only Message, File ("_Eval"), Line (0) and Column (0). It has no What, Extra or Stack, so reading e.What raises a PropertyError inside the handler; check e.HasProp("What") first. A SyntaxError your script constructs has the usual Error properties (What, Extra, File, Line, Stack) but no Column. Details: updates.md §3.

_ScriptGetLines(File, Line, Range?) — source context

Returns the parsed lines around a position as an Array of {File, Number, Text} — the primitive the debugger tooling uses to show surrounding code. Text is the engine's rendering of the line, and comments and blank lines are skipped. A negative or omitted Range returns only the given line. A line with no code returns no Array (an empty string, or no value under a #Requires AutoHotkey v2.1-... at the top level of the calling module's own file; one in an #Include file or a function no longer sets the mode), so guard the call:

for line in (_ScriptGetLines(A_LineFile, A_LineNumber, 3) ?? "") || []   ; up to 3 parsed lines either side
    Print("{:03}: {}", line.Number, line.Text)

---

Native JSON and local tools

JSON.Parse, JSON.Stringify, and JSON.Validate are built in:

values := JSON.Parse('[true,false,null]')
values[1] := "edited"
Print(JSON.Stringify(values)) ; ["edited",false,null]

Parsed arrays preserve untouched boolean/null types through edits, insertion, removal, resizing, and cloning. Assignment clears the original element's type tag; use JSON.True, JSON.False, or JSON.Null (read-only singletons) when explicitly assigning those types. JSON itself is not a constructor: JSON() throws TypeError; create objects with JSON.Parse. String values support embedded NUL characters. Object keys containing NUL are rejected with UnsupportedKey to prevent truncation and key collisions.

bin\AutoHotkey64Console.exe mcp provides the native MCP tools to a local client over stdin/stdout. It does not need a network listener. --capabilities reports the supported protocol versions and engine features. The optional bundled tree-sitter grammar DLL supports x64 only.

REPL

repl turns the binary into a persistent interpreter session: expressions arrive on stdin (terminal or pipe), results leave on stdout, state survives between lines. Built on the Eval machinery, so the loaded script's globals, functions and classes are all live.

$ bin\AutoHotkey64Console.exe repl
AutoHotkey v2.1-alpha.37+Console REPL - one expression per line; .help for commands
>>> x := 10
10
>>> x * 4
40
>>> g := Gui("+AlwaysOnTop", "Live"), g.Show("w200 h80")
>>> g.BackColor := 0x202020
2105376
>>> .exit

• repl script.ahk loads the script, runs its auto-execute section, then opens the session against its state — hotkeys, timers and GUI events keep firing throughout.
• Recoverable parse and runtime errors print one line (stderr in text mode) and the loop continues. Invalid syntax preserves existing variable lookup state.
• EOF or .exit exits 0; ExitApp(n) exits with n.
• /Diag=json produces one JSON result per input line, including blank lines, .help, and .exit. Results use the full string length, including escaped NULs. Ordinary script output (Print, FileAppend, FileOpen, and startup output) goes to stderr so stdout remains readable as JSON. Explicit ExitApp or a fatal process failure can end the session before a result is written.

{"kind":"result","ok":true,"type":"Integer","value":"42"}
{"kind":"result","ok":false,"type":"SyntaxError","value":"Missing operand."}

Spawn-per-expression is gone: an agent (or the MCP server) opens one process, writes lines, reads lines, and closes stdin when done. Full reference: updates.md §16.

---

Crash logging

/CrashLog=<path> (or the #CrashLog <path> directive) records every notable event — startup, parse errors, uncaught exceptions, fatal interpreter faults, and signal-triggered exits — to an append-only, UTF-8 log. Each record is written open-write-flush-close, so the last events survive even a hard crash. It works regardless of how the script was launched, including launchers that discard stderr.

[2026-05-13 21:35:14] [START] pid=12345 ahk=2.1-alpha.37+Console script=C:\app\app.ahk ...
[2026-05-13 21:43:22] [ERROR] pid=12345 type=MethodError mode=Return
  Message: This value of type "String" has no method named "DoStuff".
  File: C:\app\Lib\Clip.ahk
  Line: 142
  What:
  Extra:
  Stack:
C:\app\Lib\Clip.ahk (142) : [Clip.Foo] s.DoStuff()
C:\app\app.ahk (33) : [] Clip.Foo()
> Auto-execute
[2026-05-13 21:43:22] [EXIT] pid=12345 code=10 reason=Error

The Stack: lines are the error's own Stack text, written unindented with CRLF endings, so a record runs until the next [YYYY-MM-DD header line.

Event types, reason names, OnError interaction, and limitations: updates.md §4.

---

Line coverage

/Coverage=<path> writes an LCOV tracefile at exit with no script instrumentation. The parser supplies the executable lines, the interpreter's per-line dispatch counts the hits, and alpha-only syntax is counted correctly because the engine itself is the source of truth.

bin\AutoHotkey64Console.exe /Headless /Coverage=coverage\tests.lcov test tests\run.ahk
python tools\lcov_summary.py "coverage/**/*.lcov" --include "^Lib/" --badge coverage\badge.json

The engine creates a missing report directory, every level of it. If the report still cannot be written (say, the path runs through an existing file), one stderr line names the report and the Win32 error (a warning record under /Diag=json), and the exit code is the script's own (updates.md §17).

SF:C:\lib\Async.ahk
DA:12,1
DA:13,0
LF:2
LH:1
end_of_record

Structural lines (else, catch, case, braces, function headers) are not reported, so they never count against you. The file is rewritten open-write-flush-close on every exit path, including uncaught errors and fatal faults, so a crashing test still leaves partial data. Details: updates.md §17.

---

Inspecting live objects

Inspect(value, depth := 2, maxItems := 100) returns JSON describing a value without running any of its code: own values, the names of getters, setters and methods (own and inherited), array items, map entries, function signatures. Cycles and depth limits are reported, not followed. The REPL prints object results this way too.

btn := Gui().AddButton("w200", "Save")
Print(Inspect(btn, 1))
; {"type":"Gui.Button","properties":{},"getters":["Text","Type","Enabled",...],"methods":["Focus","Move","OnEvent",...]}

Details: updates.md §18.

---

Driving child processes

ProcessPipe runs a program with UTF-8 stdin/stdout/stderr pipes inside a job object, so releasing the object or calling Kill() takes the whole process tree with it. Waits keep timers and hotkeys running. It is the transport for hosting a JSONL agent server such as Codex's app-server from a script.

p := ProcessPipe("codex", ["app-server"])
p.SendLine(JSON.Stringify({method: "initialize", id: 1, params: {}}))
reply := JSON.Parse(p.ReadLine(30))   ; TimeoutError after 30 s

Details: updates.md §19. /Trace=json (§20) and the native MCP server's check/run/test tools (§21) close the loop from the other side.

---

CI for AutoHotkey libraries

GitHub's Windows runners run in an interactive session, so GUI and hotkey code works. /Headless suppresses the engine's own prompts (error dialogs, startup warnings), but a script's own MsgBox still opens a real dialog and blocks the job, so keep those out of test paths. A library repo needs three things: the engine, a single-process test entry point, and the test subcommand.

1. Fetch the engine from the latest tagged release (seconds, no build):

runs-on: windows-latest
steps:
  - uses: actions/checkout@v4
  - run: gh release download -R TrueCrimeDev/AutoHotkey -p AutoHotkey64Console.exe -D bin
    env: { GH_TOKEN: ${{ github.token }} }

This needs a published v* tag release; until one exists, gh release download fails with release not found, so build the engine per BUILD.md instead.

2. Write tests/run.ahk that #Includes the framework and every tests/*.test.ahk (copy tests/Test.ahk and tests/run.ahk from this repo). Test files register cases:

Test.Case("parses a config", () => Assert.Eq(JSON.Parse('{"a":1}')["a"], 1))
Test.Case("rejects garbage", () => Assert.Throws(() => JSON.Parse("{"), JSONError))

Test.Run() prints one line per case, exits 14 on any failure, emits ::error annotations under GitHub Actions, and writes JUnit XML when AHK_TEST_JUNIT is set. The subprocess suite qa/run.ahk writes the same shape (one testsuite per test file, one testcase per assertion) when AHK_QA_JUNIT is set.

3. Run it with coverage and machine-readable diagnostics:

  - run: bin\AutoHotkey64Console.exe /Headless /Diag=json /Coverage=coverage.lcov test tests\run.ahk 2>diag.jsonl
  - if: failure()
    shell: pwsh
    run: |
      Get-Content diag.jsonl | ConvertFrom-Json | % {
        "::error file=$($_.file),line=$($_.line)::$($_.type): $($_.message)" }

Uncaught errors become PR annotations for free. For a README number, feed coverage.lcov to codecov/codecov-action, or copy this repo's no-third-party route from build.yml: tools/lcov_summary.py computes LH/LF, writes a shields.io endpoint JSON, and the workflow force-pushes it to a badges branch that img.shields.io/endpoint reads. Each build job also has a syntax-check step (python tools/check_all.py on the engine that job just built) that parses every .ahk in a couple of seconds; the test job needs the MSVC build jobs, so it does not start after a parse failure there.

---

AI-assisted debugging

AutoHotkey64Console.exe mcp is the primary MCP surface. The engine serves MCP over stdin/stdout itself, with no Node bridge and no network listener. Its check, run and test tools spawn the engine on a file and return the exit code, captured streams and JSON diagnostics (updates.md §21); on the current build tools/list also reports ast_outline, get_source_context, server_status, source_outline and workspace_symbols. The checked-in .mcp.json registers it for Claude Code as ahk-mcp, and tests/test_mcp_protocol.py pins the protocol envelope.

The fork also preserves AutoHotkey's DBGp debugger. The legacy DBGp bridge (debugger-tool/mcp-server/) is a separate Node MCP server that drives it for LLM tools such as Claude Code and Cursor; until roadmap A1 completes the debugger protocol, breakpoints, stepping, stack and variable inspection and error capture live only there. Combined with the structured errors above, this closes a tight loop:

run script → capture structured error → inspect source / variables → apply fix → re-run

The bridge speaks DBGp on port 9000, or supervises the engine over /Debug=stdio with launch_script, and surfaces 28 tools:

Group	Tools
Supervision	launch_script, terminate_script, get_script_output
Execution	debug_run, debug_step_into / _over / _out, debug_stop, debug_status, debug_command
Breakpoints	breakpoint_set, breakpoint_remove, breakpoint_list
Inspection	variables_get, evaluate, stack_trace, watch_add / _remove / _list
Source intel	get_source_context, source_outline, ast_outline, workspace_symbols
Error loop	capture_error, analyze_error, apply_fix
Queue	list_errors, clear_errors

Start it (the server must be listening before the script connects; otherwise the script runs without the debugger and says so on stderr):

cd debugger-tool\mcp-server
npm install && npm run build
node build/index.js

bin\AutoHotkey64Console.exe /Debug your_script.ahk    # connects to localhost:9000

Tool-by-tool usage lives in debugger-tool/mcp-server/README.md.

For Claude Code, the ClautoHotkey plugin wraps this engine in post-edit validation hooks and a grading harness. The harness docs are on the site: Static & dry-run gates and MCP integration.

---

Repository map

Path	Purpose
source/	AutoHotkey engine source (C++) — fork changes live here
debugger-tool/mcp-server/	Legacy DBGp bridge: a Node MCP server for breakpoints, stepping and error capture
debugger-tool/ahk-error-agent/	Headless error-capture and fix-automation agent
examples/	Runnable feature demos — alpha21/, alpha22/, plus structs, GUIs, and ANSI showcases
examples/Alpha22_Example.ahk … examples/Alpha30_Example.ahk	Per-version language showcases
tests/	run.ahk + *.test.ahk single-process suite, Test.ahk framework, Python console-gate suites
qa/	Subprocess-per-test interpreter regression suite
tools/	check_all.py (parse every .ahk), lcov_summary.py (merge coverage, badge JSON), vscode/ (AutoHotkey2 LSP syntaxes generator and a tasks.json template with the /Diag=json problem matcher; see docs/VSCODE_SETUP.md)
BUILD.md	Build instructions

---

Documentation

Document	Covers
Docs site	Console + ClautoHotkey guides, recipes, showcase (built from website/)
ClautoHotkey harness	Static & dry-run gates, ahk-harness/result@1 schema, CheckResults.py
updates.md	Authoritative reference for every fork addition
BUILD.md	Toolchains, build configs, troubleshooting
CLAUDE.md	Project orientation for AI agents
V3_MILESTONE_STATUS.md	Milestone implementation status
docs/TREE_SITTER.md	Vendored tree-sitter AHK grammar DLL: exports, DllCall usage
docs/VSCODE_SETUP.md	VS Code: tasks, launch configurations, the /Diag=json problem matcher, and workspace-wide fork declarations for the AutoHotkey2 LSP (AutoHotkey2.Syntaxes)
debugger-tool/mcp-server/README.md	MCP tool reference and setup

---

License

This fork inherits AutoHotkey's GNU GPL v2 license — see license.txt. It is a specialized fork, not a claim of upstream parity; for stock behavior, use an official AutoHotkey build. Built on AutoHotkey v2.1-alpha by Lexikos and contributors.