pingdotgg / pingdotgg/t3code

[Bug]: One submitted prompt spawned a second, invisible agent session on a different model, which ran gh write commands unsupervised

Open
#5,447 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
23k
Forks
5.9k
Avg merge
11h 14m
Merged PRs (30d)
357

Description

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/desktop

Scope — what is and isn't this report

The bug being reported is only the session dispatch/visibility behavior:

  1. One submitted prompt created two agent sessions.
  2. The second session was invisible in the UI — no thread, no permission surface — while holding the same credentials/tool access as the visible one.
  3. The second session ran a different model at different effort (claude-haiku-4-5, no thinking) than the thread's configuration (claude-fable-5, effort high).

What the duplicate then did with that access (it made poor triage decisions and closed issues in my repo) is not a T3 problem — that's just the model doing a mediocre job of a repo-specific workflow, and it's only mentioned because external side effects are how an invisible session gets noticed at all. Please read every mention of issue-closing below as "evidence the hidden session ran and wrote", not as a complaint about agent output quality.

Steps to reproduce

Observed once; I don't have a deterministic repro yet, but full forensics are below so hopefully the dispatch path can be audited.

  1. Windows desktop app (Alpha 0.0.31), provider Claude Code, thread model claude-fable-5 at effort high.
  2. Submit a single prompt in one thread (mine asked the agent to audit/triage GitHub issues in a repo of mine, using gh).
  3. One visible thread starts as expected — but a second Claude session is spawned the same second, invisible in the UI.
Expected behavior

One submitted prompt → one agent session, visible as a thread, running the model/effort configured for it, with tool permissions surfaced in the UI.

Actual behavior

Two sessions were created for the one submit (transcript files in ~/.claude/projects/<dir>/ timestamped 19:52:56.078Z and 19:52:56.360Z; the duplicate's transcript opens with a title-generation call quoting my prompt verbatim, then executes the task itself).

The duplicate:

  • ran on claude-haiku-4-5 with no extended thinking, not the thread's configured model;
  • was not visible anywhere in the UI — no thread, no permission prompts;
  • executed write operations against GitHub via gh (issue closes / label edits in three PowerShell batches) about 60 seconds in, then exited after ~2 minutes — which is how I noticed: tracker state changed under my visible session mid-task.

Both the visible session's process and the duplicate were children of the app's server process (T3 Code (Alpha).exe ... apps/server/dist/bin.mjs --bootstrap-fd 3).

Impact

Major degradation or frequent failure — a hidden session performed external writes under my GitHub identity with no way to see or stop it. Recoverable in my case.

Version or commit

Desktop Alpha 0.0.31 (Windows installer, T3 Code (Alpha).exe ProductVersion 0.0.31.0)

Environment

Windows 11 Home 10.0.26200; provider Claude Code (CLI at ~/.local/bin/claude.exe); thread model claude-fable-5 effort high; duplicate ran claude-haiku-4-5.

Logs or stack traces
# Spawned CLI (child of T3 Code (Alpha).exe server process):
claude.EXE --output-format stream-json --verbose --input-format stream-json
  --effort high --model claude-fable-5[1m] --permission-prompt-tool stdio --mcp-config "{...}"

# Duplicate session transcript (7ef79db8…): first entry 19:52:56.078Z is a
# title-generation queue item quoting the submitted prompt; model on its
# assistant turns is claude-haiku-4-5-20251001; 0 thinking blocks.
# Its three mutating tool calls (shown as evidence of unsupervised writes):
19:53:55Z PowerShell: foreach ($n in @(...)) { gh issue close $n --comment "..." }
19:54:29Z PowerShell: foreach ($n in @(...)) { gh issue edit $n --remove-label ... }
19:54:46Z PowerShell: Write-Host "... keeping as-is."
# Last activity 19:55:04Z, process exited.
Workaround

None found — the duplicate isn't visible, so the only mitigation was auditing the external side effects afterwards. Happy to share redacted transcript excerpts if useful.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the apps/server/dist/bin.mjs bootstrap entry point and the desktop submit/dispatch path, using the two timestamped transcripts under ~/.claude/projects/

/ as investigation evidence. Trace why title generation can create a second Claude session, then verify that one submission produces one visible session using the configured model and permission surface.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
desktop, security
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.