All issues

[code-review] Manager.Stop reads m.encoder only once and skips enc.Stop when nil - so a Stop issued inside the first-tick window (encoder spawn + font loading spans ~100ms; Go's select picks randomly between the ready stopCh and tick cases) returns cleanly while frameLoop's first-frame init then completes AFTER Stop: the encoder ffmpeg process, target ffmpeg processes and broadcaster goroutines leak with no one left to reap them, and a second Start overwrites the stale encoder reference, cementing the leak; also #1601-B's dedup key uses filepath.Abs which never expands a tilde prefix while loadGoPlugin itself does - a config path of ~/.ggcode/plugins/x.so gets loaded for real but keyed as cwd/~/..., never matching scanDir's exclusion key, double-loading the .so and failing startup on duplicate tool names

#1631

· topcheer opened

on Sep 4, 2026

[code-review] #1597-A's same-name plugin reload fix registers the NEW adapter before killing the OLD instance - the duplicate-name registration fails (tool.go:121 'already registered', only a debug warning), then the old process is killed, leaving the registry pointing at a dead process: every tool of that plugin RPC-fails until restart, a regression from the pre-fix 'leaked but alive and working' state (tool.Unregister exists at tool.go:137 and is never called anywhere in the grpc package); also stream quality is validated and stored but buildArgs never reads it (bitrate hardcoded 5000k both paths), and WriteFrame holds e.mu across a blocking stdin write so an RTMP stall deadlocks Stop entirely - the write-side twin of the read-side bug #1294 already fixed

#1630

· topcheer opened

on Sep 4, 2026

[code-review] dangerous.go raw-device table misses macOS rdisk (r prefix escapes the disk regex branch) plus mapper/loop/dm-/xvd - verified false in a regex matrix, so burning an image to a raw block device on macOS needs zero confirmation under bypass/autopilot; the /dev/tcp family is equally invisible - redirecting a secret to a bash TCP socket matches NONE of network.go's 27 patterns (not even NetworkAccess), a silent exfil path #1596 never covered; #1595 direction semantics half-applied - old L83 still flags safe device READS as Critical; new -F pattern lacks the @-anchor its reason string claims

#1629

· topcheer opened

on Sep 4, 2026

[code-review] loadSession's dedup uses a global content-fingerprint key (role+blocks, no timestamp/position) for legacy messages without IDs, so a user legitimately sending the same short reply twice ('继续'/'y') has every occurrence after the first silently dropped on EVERY load - the comment at store.go:3140 admits the risk while the corruption this dedup targets (restore double-append) only ever produces ADJACENT copies, so adjacent-only dedup would suffice; meanwhile #1584-A's poster-child scenario - a text-less image send - still fails to fire the Knight activity hook because onActivity is gated on text != '' (daemon.go:847 wires it straight to NotifyActivity, so an actively messaging user reads as idle), and ProviderContent's fallback block (types.go:114) guarantees len(content)>=1, leaving BOTH empty-message drop gates in daemon_bridge.go:475/484 as dead code

#1628

· topcheer opened

on Sep 4, 2026

[code-review] 136463b7's #1583-A claims 'All three receive endpoints' but there are FOUR - handlePresence (handlers.go:172, POST /lanchat/presence via AuthMiddleware) still decodes r.Body with no MaxBytesReader, and since json.Decoder buffers an oversized string value entirely before failing (scratch-verified) and net/http has no default body cap, any LAN host can pass the ZERO-CONFIG auth (communityKey is a public in-code constant, the code's own comment admits it) and POST a multi-GB body to blow up memory - the UDP transport has a 4MB decompressed cap but HTTP presence is the sole uncapped receive path; receipt/nick also return 400 instead of the promised 413 on MaxBytesError (only the message endpoint got the errors.As branch), and hub.go:913 decodes the presence RESPONSE uncapped on the send side

#1627

· topcheer opened

on Sep 4, 2026

[code-review] display_redact's multi-group branch returns sub[1]+maskValue(sub[2])+sub[len(sub)-1] - for the only two 2-group patterns (aws_secret_access_key, azure_account_key_conn) the trailing sub[len-1] IS the raw key, so 'AWS_SECRET_ACCESS_KEY=wJal...EKEY' renders as the mask FOLLOWED BY the complete plaintext, pushing the secret to TUI chat echo, IM outbound messages, and desktop rendering (the redaction layer itself copies the key to screen); separately the PEM rule at L40 requires at least one prefix char before PRIVATE KEY ('[A-Z ]+'), so bare PKCS#8 '-----BEGIN PRIVATE KEY-----' - the format virtually all modern SDK private keys use - passes through unmasked even though the detection layer's optional-group regex DOES catch it, the 4th recurrence of the detect-vs-display drift family (#1289/#1306)

#1626

· topcheer opened

on Sep 4, 2026

[code-review] starting ggcode in a parent directory of all projects (e.g. /Volumes/new/ggai) balloons code-index memory to tens of GB - fixed by 283c577a

#1625

· topcheer opened

on Sep 4, 2026

[code-review] 6d764875's #1582 knight half ('CJK runes in validator token sets') hardcodes the same Han-only U+4E00-9FFF range that #1622 already flagged in similarity.go - the two files share jaccard but each pins the identical incomplete range, so Korean word-variant and Japanese kana near-duplicates tokenize to nearly-disjoint sets (J≈0) and rewrite-plagiarism slips past the 0.75 CheckDuplicate gate at scheduler.go:624/871/1900; the single-rune loop also has no stopword filter on either side, and two 8-char Chinese descriptions differing in one character score J=(n-1)/(n+1)=0.78 (n=7 crosses 0.75), falsely rejecting distinct skills the len>20-byte gate can't block; meanwhile runfile's kill-0 liveness check carries no process identity, so a recycled PID keeps a dead instance's port file 'alive' forever (deletion happens exclusively in the dead-pid branch per #791's own comment), accumulating ghost entries on long-running shared machines

#1624

· topcheer opened

on Sep 4, 2026

[business-logic] logging-intel's sensitive-variable detection runs in two stages with contradictory semantics: the pattern stage uses \b-anchored matching (the #1098 comment says the boundary was added precisely to avoid tokenCount/maxTokens false positives), but the final verdict at L313-317 is a bare strings.Contains - so 'log.Printf("token issued for %s", maxTokenCount)' hits \btoken\b inside the message literal in stage 1, survives string-stripping as ', maxTokenCount)', and Contains('maxtokencount','token') fires a CRITICAL sensitive-log finding that coaches the agent to 'fix' correct code (scratch-verified; the same family as #1581-A but in the opposite direction); also stripStringLiterals defaults to JS semantics (a landmine for future Go callers) and countSensitiveLogArgs/countFatalInLib are dead code

#1623

· topcheer opened

on Sep 4, 2026

[code-review] 859a9a75's #1580 CJK fix only widens the tokenizer to Han U+4E00-U+9FFF, so the original symptom - descriptions tokenizing to an empty set with jaccard pinned at 0 - still reproduces verbatim for Korean (Hangul U+AC00+ yields literally 0 tokens, scratch-verified), Japanese kana are silently dropped leaving only kanji fragments (fingerprint distortion), Ext-A and compatibility ideographs are missed, and full-width ASCII (U+FF01-FF5E, common when pasting from Chinese web pages) falls between both loops so '版本Ｖ１．２' and '版本' collapse to identical fingerprints with jaccard 1.0 - the fix also shipped with zero direct test rows to lock it in; meanwhile the live restart Launch path (called from daemon.go and repl.go, not dead code as first assessed) creates a predictable /tmp/ggcode-restart-<PID>.sh via os.Create (symlink-following) and hardcodes /bin/bash

#1622

· topcheer opened

on Sep 4, 2026

[business-logic] the irrev gate tiers git tools by NAME alone, so the same schema-encoded destructive-subaction pattern #1579-A just fixed for git_reset lives on in its siblings: git_stash {"action":"drop"} sits in the blanket Low tier (the tool's own Description says 'pop and drop are destructive', dropping a stash permanently discards uncommitted work with zero grounding and zero warning) and the shell pattern table lists 'git branch -d'/'git tag -d' but not 'stash drop', leaving BOTH paths blind; git_tag {"action":"delete"} is Tier 0 'read-only' while the same file's own pattern table at L166 calls 'git tag -d' destructive - an internal contradiction; and {"mode":"hard","files":[...]} is really a reversible per-file mixed unstage per git_reset.go's own docs yet fires a HIGH-IMPACT warning

#1621

· topcheer opened

on Sep 4, 2026

[code-review] db2f97d1's fatal-dump tee self-negates: when a stderr line matches looksFatal (the fix's ONLY target event - the runtime fatal banner), the inner line-splitting loop at main.go:121-147 consumes the line, prepends it BACK into buf at L138, then 'continue's the SAME inner loop at L143 - the identical line is re-extracted, looksFatal is deterministic prefix matching, so buf oscillates between two states forever: mu never unlocks (L148 unreachable), the reader goroutine never reads again so the real fatal dump blocks on the 64KB pipe (process HANGS instead of crashing - TUI freeze), the crash file fills with the repeated banner line (repro: 7MB in 500ms) while the actual stack never lands, and disk fills unboundedly; 'continue' must be 'break' so the L107 raw branch takes over

#1620

· topcheer opened

on Sep 4, 2026