GitLens/GitKraken MCP repeatedly unpacks gk CLI to temp, consuming disk space on macOS

[alejandroiglesias]

Summary

GitLens 18.0.0 in Cursor appears to be repeatedly running the bundled GitKraken CLI command:

$HOME/Library/Application Support/Cursor/User/globalStorage/eamodio.gitlens/gk ai hook list-sessions --json

Each invocation creates a new macOS temp directory named gkinstall* under $TMPDIR, around 42 MB each, containing a fresh gk binary, gk_core_3.1.66_darwin_arm64.zip, and MCP resources. The directories are not being cleaned up, so disk usage grows continuously until the Mac runs out of space.

This happened while the machine was idle / no manual disk-writing operation was intentionally triggered.

Impact observed

On 2026-05-31 at 03:26:29 -03, the APFS Data volume was nearly full:

Filesystem      Size    Used   Avail Capacity Mounted on
/dev/disk3s5   926Gi   855Gi    14Gi    99%   /System/Volumes/Data

The GitKraken/GitLens temp install directories accounted for 64 GB:

find "$TMPDIR" -maxdepth 1 -type d -name 'gkinstall*' | wc -l
# 1789

find "$TMPDIR" -maxdepth 1 -type d -name 'gkinstall*' -mmin -10 | wc -l
# 30

du -sh "$TMPDIR"
# 64G

The current creation rate was about 30 temp dirs per 10 minutes. Since each directory is ~42 MB, that is roughly 126 MB/minute, or ~7.5 GB/hour, with three Cursor windows/extension hosts open.

A representative latest temp directory:

$TMPDIR/gkinstall1684973017                              42M
$TMPDIR/gkinstall1684973017/gk
$TMPDIR/gkinstall1684973017/gk_core_3.1.66_darwin_arm64.zip
$TMPDIR/gkinstall1684973017/mcp_resources/vendor.meta.json
$TMPDIR/gkinstall1684973017/mcp_resources/manifest.json
$TMPDIR/gkinstall1684973017/mcp_resources/vendor.bundle.js.gz

Live process evidence

While watching the directory, new gkinstall* folders appeared at the same time as Cursor extension host children launched gk ai hook list-sessions --json.

Example captured at 2026-05-31 02:57:13 -03:

$TMPDIR/gkinstall2404347799 created

26240  parent=9589  $HOME/Library/Application Support/Cursor/User/globalStorage/eamodio.gitlens/gk ai hook list-sessions --json
26245  parent=9590  $HOME/Library/Application Support/Cursor/User/globalStorage/eamodio.gitlens/gk ai hook list-sessions --json
26250  parent=9591  $HOME/Library/Application Support/Cursor/User/globalStorage/eamodio.gitlens/gk ai hook list-sessions --json

The parent processes were Cursor extension hosts, one per open window/workspace:

Cursor Helper (Plugin): extension-host (user) [window/workspace 1]
Cursor Helper (Plugin): extension-host (user) [window/workspace 2]
Cursor Helper (Plugin): extension-host (user) [window/workspace 3]

Environment

macOS: 15.7.4 (24G517)
Arch: arm64
Cursor: 3.6.21
GitLens extension: eamodio.gitlens 18.0.0 universal

The bundled gk in Cursor global storage:

Path: $HOME/Library/Application Support/Cursor/User/globalStorage/eamodio.gitlens/gk
Size: 19M
Mach-O: arm64
Signature: Developer ID Application: Axosoft, LLC (T7QVVUTZQ8)
Timestamp: 15 May 2026 at 6:31:36 AM
Runtime Version: 12.1.0

A temp gkinstall* gk binary was also signed by Axosoft and appeared to be a newer/staged CLI payload:

Path: $TMPDIR/gkinstall.../gk
Mach-O: arm64
Signature: Developer ID Application: Axosoft, LLC (T7QVVUTZQ8)
Timestamp: 29 May 2026 at 2:15:14 PM

Relevant logs

Cursor MCP logs for user-eamodio.gitlens-extension-GitKraken showed successful connection, then JSON parse failure / transport error:

2026-05-30 01:53:34.148 [info] [V2] Handling CreateClient action
2026-05-30 01:53:34.813 [info] Successfully connected to stdio server
2026-05-30 01:53:34.820 [info] CreateClient completed, connected: true, statusType: connected
2026-05-30 04:03:51.268 [error] Client error: Unexpected token 'c', "command fa"... is not valid JSON Unexpected token 'c', "command fa"... is not valid JSON
2026-05-30 04:03:51.284 [warning] [V2 FSM] connection:transport_error: conn=connected,auth=unknown -> conn=failed,auth=unknown

GitKraken CLI log snippets around the same GitLens connection:

{"level":"warning","msg":"GL connection valid (version: 18.0.0)","time":"2026-05-30T01:53:33.093666-03:00"}
{"level":"warning","msg":"Found discovery file for address $TMPDIR/gitkraken/gitlens/gitlens-ipc-server-...json","time":"2026-05-30T01:53:33.095393-03:00"}
{"level":"warning","msg":"User not authenticated, skipping fetch prompts","time":"2026-05-30T01:53:33.706769-03:00"}

There were also many repeated telemetry flush/shutdown failures:

{"error":"context deadline exceeded","level":"warning","msg":"otel flush failed",...}
{"error":"context deadline exceeded","level":"warning","msg":"otel shutdown failed",...}
{"error":"traces export: Post \"https://otel.gitkraken.com:4318/v1/traces\": dial tcp: lookup otel.gitkraken.com: no such host","level":"warning","msg":"otel flush failed",...}

Expected behavior

Running gk ai hook list-sessions --json should not create a fresh 42 MB temp install directory on every invocation. If the CLI needs to stage/update itself, it should either:

• reuse one cached install location,
• clean up temporary gkinstall* directories after successful/failed runs,
• avoid concurrent per-window installs, and/or
• avoid retry loops that continuously extract the CLI payload.

Actual behavior

Every minute, each Cursor/GitLens extension host appears to run gk ai hook list-sessions --json, and each run creates a new $TMPDIR/gkinstall* directory that remains on disk. With three Cursor windows this caused rapid growth and consumed 64 GB of temp data.

Workaround

Disabling/uninstalling the GitLens/GitKraken integration in Cursor should stop new folders from being created. Existing $TMPDIR/gkinstall* directories still need to be removed manually after Cursor/GitLens is stopped.

Possible root cause

It looks like gk ai hook list-sessions --json is entering the CLI install/update path and extracting gk_core_3.1.66_darwin_arm64.zip to a fresh temp directory on each call. The MCP JSON parse error (Unexpected token 'c', "command fa"...) may be related if non-JSON CLI output is causing the Cursor MCP client to mark the transport failed and later retry.

[dominiceloe]

Same symptom here (GitLens 18.0.0, macOS arm64, gk_core 3.1.66) — but I think I found the root cause, which I don't see identified in this thread or in #5249: the install fails on every attempt, so the core is never cached and gets re-extracted to a fresh gkinstall* temp dir forever.

The failure is a file-vs-directory collision in ~/Library/Application Support/GitKrakenCLI/versions/.

What's happening

AUTO_UPDATE=true tries to install core 3.1.66. The installer does a bare mkdir versions/gk_3_1_66, but a pre-existing file named gk_3_1_66 (from the old file-based layout — earlier versions stored each core as a file: gk_3_1_53, gk_3_1_54, gk_3_1_65, all files) already occupies that path. So mkdir fails with not a directory every single time:

install failed:
    main.installUnderLock
        gkcli/cmd/installer-proxy/main.go:489
  - failed to create version directory:
    gkcli/internal/installerproxy.(*svc).Install
        gkcli/internal/installerproxy/service.go:137
  - failed to create version directory:
    gkcli/internal/installerproxy.(*svc).installNewestVersion
        gkcli/internal/installerproxy/service.go:191
  - failed to create version directory:
    gkcli/internal/installerproxy.(*svc).installDownloadedVersion
        gkcli/internal/installerproxy/service.go:993
  - mkdir .../GitKrakenCLI/versions/gk_3_1_66: not a directory

The loop, straight from gk_cli_proxy.log — download → fail → retry, ~every 15s (and 2× back-to-back each time the AI hook fires):

[07:14:58] downloading latest binary
[07:14:58] downloading binary: .../gk_core_3.1.66_darwin_arm64.zip to /var/folders/.../T/gkinstall<rand>/
[07:14:58] install failed
[07:15:00] downloading latest binary
[07:15:00] downloading binary: .../gk_core_3.1.66_darwin_arm64.zip to /var/folders/.../T/gkinstall<rand>/
[07:15:00] install failed
[07:15:22] ... (repeats indefinitely)

In my case: 1,450 logged failures in ~8 hours, and over ~3 days it produced 8,415 gkinstall folders ≈ 345 GB, taking the disk down to 1.4 GB free. (This also explains why gitlens.gitkraken.mcp.autoEnabled: false doesn't help in #5249 — the gk ai hook list-sessions poll is a separate trigger, and each invocation hits the same failing install path.)

Two compounding bugs

1. No migration from the file-based layout to the directory-based layout. installDownloadedVersion should detect/remove/migrate a non-directory occupying the target version path before mkdir (or stage to a temp dir + atomic rename).
2. Failed installs never clean up their extraction. Each failed attempt leaves the ~42 MB gkinstall* temp dir behind. Even ignoring bug Support blame on files outside the workspace repository #1, a defer/cleanup on the temp dir would have prevented the unbounded disk fill.

Workaround that actually fixes it (keeps GitLens working)

Unlike disabling gk entirely, this lets the install complete correctly:

cd ~/Library/Application\ Support/GitKrakenCLI/versions
mv gk_3_1_66 gk_3_1_66.bak     # move the stale blocking FILE aside
# within ~15s the next retry creates versions/gk_3_1_66/ as a proper directory and the install succeeds

After this, versions/gk_3_1_66/ became a real directory (binary + mcp_resources/), the install failed errors stopped, and 0 new gkinstall folders were created (was 3–4 per 30s). Then it's safe to reclaim the leaked space:

find /var/folders/*/*/T -maxdepth 1 -name 'gkinstall*' -type d -print0 | xargs -0 rm -rf

Environment

• macOS 15.6.1 (arm64)
• VS Code 1.51.1, GitLens 18.0.0
• gk_core 3.1.66, AUTO_UPDATE=true
• Trigger: gk ai hook list-sessions --json polling (~15s)

Attaching the full scrubbed gk_cli_proxy.log if useful.

gk_cli_proxy.SCRUBBED.log