[Bug]: TWG 1.2.7 emits successful output but does not exit on macOS ARM64

[addlatt]

Environment

• TWG CLI: 1.2.7
• Install method: direct public installer
• OS: macOS 26.6.2, Darwin 25.6.0
• Architecture: arm64
• Authentication: OAuth; twg doctor reports a valid token and healthy connectivity

Reproduction

Run:

TWG_DIAG=1 twg whoami

The command prints the authenticated user successfully. The diagnostic output reports an HTTP 200 response from api.atlassian.com/graphql in under one second and a completed command profile in under one second, but the process remains alive and does not return to the shell.

The same behavior occurs with:

twg api jira:/rest/api/3/myself
twg rovo list-apps --output json
twg doctor
twg update

twg update successfully reported that it updated 1.2.5 to 1.2.7 and refreshed the skills/help cache, but the update process also remained running afterward.

Expected behavior

After the successful response and output are emitted, the process should exit promptly.

Actual behavior

The response is complete, but the process remains alive. Programmatic callers and agents hit their timeout and fall back to MCP or REST API access.

Additional evidence

• Local-only commands such as twg env auth --no-snapshot exit normally in under one second.
• Direct curl requests to the Atlassian API and developer host complete in roughly 0.3–0.7 seconds.
• The following did not resolve the behavior:
  • TWG_BACKGROUND_UPDATE_CHECK=0
  • DO_NOT_TRACK=1
  • TWG_AGENT_DEFAULTS=1
  • TWG_TIMEOUT_MS=1000
  • BUN_CONFIG_HTTP_IDLE_TIMEOUT=1
  • HTTP Connection: close
• While stuck, the process retains established HTTPS connections to api.atlassian.com; process sampling shows Bun's HTTP client thread idle in kevent.

This appears to be a post-request shutdown or HTTP-client handle cleanup issue in the macOS ARM64 build. Please advise whether this is a known issue in 1.2.7 and whether a supported workaround or patched build is available.

[luke321]

Corroborating this on Windows x64 — same version, same signature. So this is not specific to the macOS ARM64 build.

Environment: TWG CLI 1.2.7, Windows 11 Enterprise 10.0.26200, x64, OAuth (healthy, doctor clean).

Same repro, same result

TWG_DIAG=1 twg whoami:

[profile] rest POST api.atlassian.com/graphql 298ms 200 trace=65febe38...
Profile: twg whoami
  total requests: 1
  rest    POST /graphql        298ms  200
  total                       1177ms

Complete, correct stdout (497 bytes) on disk at 2.26s. Process still alive at 100s, and still alive at 422s when I stopped watching. CPU flat across the wait — sampled 2.094s → 2.094s over a 5-second interval, i.e. a delta of exactly zero. It is wedged, not slow.

Windows thread states at that point (18 threads, none running):

Wait, EventPairLow  x5
Wait, Unknown       x9
Wait, UserRequest   x2

That is the Windows equivalent of the "Bun HTTP client thread idle in kevent" you saw — everything parked in a wait, nothing making progress, with the answer already emitted.

It is intermittent, not per-command

Worth flagging because it makes bisecting painful: the same command hung on one run and exited in 3.08s on the next, with no config change in between. Six runs on this machine within about ten minutes:

Command	Result	Output emitted at
whoami	HUNG (>422s)	2.26s
whoami	exited 3.08s	2.45s
doctor	HUNG (alive at 75s)	12.09s, 2401 bytes complete
update --check	exited 4.28s	2.71s
api jira:/rest/api/3/myself	HUNG (alive at 75s)	4.00s, 1043 bytes complete + correct
jira workitem get --id … (bad flag)	exited 2.37s	n/a — argument error

3 hangs in 6. Note api hangs too, which matches your list.

Two things that may help narrow it

1. The one run that exited immediately never opened an HTTP client. The --id run failed argument parsing before making any request and exited in 2.37s. Every hang I have observed followed a successful HTTPS request that had already returned 200. Only one error-path sample, so treat it as a hint rather than a result — but it is consistent with your post-request client-teardown theory rather than with anything in command dispatch.

2. The scheduled self-updater hangs too, so processes accumulate on a timer. On Windows the installer registers an upkeep Task Scheduler job that runs every ~12 minutes. I caught twg.exe upkeep run --scheduled in the same wedged state. That means a machine leaks a lingering twg.exe on a schedule even when the user runs no commands at all. I had 8 live twg.exe processes at once, oldest 826s, without doing anything unusual:

 33420  age=826s  jira workitem update --id … --status "In Progress" --assignee me
 26288  age=610s  jira board sprints query --issue …
 39268  age=373s  whoami
 47176  age=310s  upkeep run --scheduled
  6808  age=201s  doctor
 21488  age=119s  api jira:/rest/api/3/myself
 29172  age= 39s  confluence content get … -o json

Why this bites harder than it looks

Any agent or script that shells out to twg and waits on process exit hangs with it, even though the payload is complete and correct on disk. The workaround we use is to read the output file and kill the process rather than wait for exit — but that only works if you know to do it, and it is unsafe to apply blindly to writes, since a hung write has usually already landed and a retry duplicates it (a hung comment create posts twice).

Happy to run any diagnostic build or capture a stack dump on Windows if that would help.

[neozenith]

Confirming this on an independent host, plus two findings not yet in the thread: the threads are not idle, they spin, and twg upkeep turns this into an unattended CPU leak.

This was particularly noticeable when getting codex to leverage twg to update mutiple child issues on an Epic.
It ran multiple batch exec and left 20+ processes hanging and a laptop sounding like a blackhawk helicopter that even noising cancelling headphones couldn't cancel.

Here is a methodical report Codex/Claude helped me curate and diagram. The problem is intermittent and I do empathise to whomever picks up and traces down an intermittent bug.

	Reported above	This host
Version	1.2.7	1.2.7
OS / arch	Darwin 25.6.0, arm64	Darwin 25.6.0, arm64
Endpoint held open	api.atlassian.com	teamwork-graph.atlassian.com (CloudFront)

Different endpoint, same failure — so this isn't specific to one host or one API.

It is also intermittent. Two runs of twg update --check minutes apart, identical output both times: one exited 0 in 2 seconds, the next was still resident at 3m17s when I killed it.

---

1. The threads are not idle — they spin

The report above describes the HTTP client thread as idle. Thread-level sampling says otherwise. Two ps -M samples ~13s apart on a hung PID:

%CPU STAT     UTIME  THREAD
 5.6 S      0:06.41  main-thread
 0.2 S      0:00.24  libpas scavenger
13.9 S      0:14.59 -> 0:17.26  Heap Helper Thread
14.1 S      0:14.56 -> 0:17.24  Heap Helper Thread
13.6 S      0:14.47 -> 0:17.13  Heap Helper Thread

Three JavaScriptCore Heap Helper threads climb ~2.7s of user time each per 13s of wall clock. A hung twg burns ~47% of a core continuously, not 0%. sample(1) names the runtime — JavaScriptCore libpas scavenger, Heap Helper x3, Bun Pool 0-2, HTTP Client. Frames resolve to ??? (in twg); the binary is stripped.

2. twg upkeep accumulates orphans

This is the part that matters operationally. Scheduled upkeep runs hit the same path, hang the same way, and get reparented to init — where nothing owns or watches them. Found on this machine:

  PID  PPID STAT  ELAPSED  %CPU      TIME COMMAND
16223     1 S    22:02:43  47.1  74:01.09 /Users/jpeak/.local/bin/twg upkeep run --scheduled

22 hours resident, 74 minutes of CPU consumed, identical thread signature to the foreground hang. The user never invoked it directly. Each scheduled firing that hangs adds another.

3. Mechanism: a keep-alive socket left registered on kqueue

lsof on a hung PID:

FD 10u  IPv4  TCP 100.64.0.1:60550->13.32.45.5:443 (ESTABLISHED)
FD 3u   KQUEUE  count=0, state=0x12
FD 7u   KQUEUE  count=0, state=0x10
FD 11u  KQUEUE  count=0, state=0x12

Every kqueue is at count=0 — zero pending events, no work left — yet FD 10 is still ESTABLISHED. The endpoint is https://teamwork-graph.atlassian.com/cli/manifest.json, and its response explains why the socket lingers:

HTTP/1.1 200 OK
Content-Length: 2472
Connection: keep-alive        <- retained for reuse, never unref'd
Server: AtlassianEdge

The origin is behaving correctly; Connection: keep-alive is a legitimate invitation to reuse. The client accepts it and never tears the pool down, so the loop's handle refcount never reaches zero.

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#2563eb','primaryTextColor':'#ffffff','primaryBorderColor':'#1e40af','lineColor':'#334155','actorBkg':'#2563eb','actorTextColor':'#ffffff','actorBorder':'#1e40af','actorLineColor':'#64748b','signalColor':'#334155','signalTextColor':'#1e293b','labelBoxBkgColor':'#7c3aed','labelBoxBorderColor':'#5b21b6','labelTextColor':'#ffffff','loopTextColor':'#1e293b','noteBkgColor':'#ffffff','noteBorderColor':'#b45309','noteTextColor':'#1e293b','activationBkgColor':'#7c3aed','activationBorderColor':'#5b21b6','sequenceNumberColor':'#ffffff'}}}%%
sequenceDiagram
    autonumber
    participant MT as twg main thread
    participant HC as HTTP Client thread
    participant KQ as kqueue event loop
    participant CF as CloudFront edge
    participant OS as kernel

    rect rgb(209, 250, 229)
    Note over MT,CF: the request itself succeeds
    MT->>HC: fetch /cli/manifest.json
    HC->>CF: TLS + GET to 13.32.45.5:443
    HC->>KQ: register FD 10 as ACTIVE HANDLE
    CF-->>HC: 200 OK, 2472 bytes, Connection: keep-alive
    HC-->>MT: manifest parsed, latest = 1.2.7
    MT-->>OS: stdout "twg is up to date (1.2.7)"
    Note over MT: work is complete here
    end

    rect rgb(254, 226, 226)
    Note over MT,OS: shutdown, where it diverges
    MT->>KQ: main module returned, may I exit?
    KQ->>KQ: poll -> count=0, nothing pending
    alt socket released in time (observed once, exit 0 in 2s)
        HC->>KQ: FD closed, refcount decremented
        KQ-->>MT: refcount == 0, exit granted
        MT->>OS: exit(0)
    else socket still parked in keep-alive pool (observed: hang)
        KQ-->>MT: FD 10 still registered, refcount != 0
        loop until SIGTERM
            Note over KQ: nothing to poll, still cannot exit
            MT->>MT: Heap Helper x3 spin at ~18% CPU
        end
    end
    end

Loading

Deterministic reproduction

exec replaces the shell image, so the printed PID is twg's — no sampling race:

zsh -c 'echo "twg_pid=$$" >&2; exec twg update --check'

# then, from another shell:
lsof -p <PID> | grep -E 'KQUEUE|TCP'
ps -M <PID>          # sample twice - rising UTIME means spinning, not blocked
sample <PID> 3       # names the runtime threads

# find accumulated orphans:
ps -eo pid,ppid,etime,time,%cpu,command | grep '[t]wg upkeep'

Likely fix

Dispose the fetch agent / connection pool once the command completes, or process.exit() after stdout is flushed. Same class as oven-sh/bun#13184 and oven-sh/bun#25975.

Given the upkeep accumulation, a documented way to disable scheduled upkeep would be a useful interim mitigation — killing the orphan only clears the symptom until the next firing.