Thirteen Merges, 177 Bug Reports, and One Rescue Mission: My August in Open Source

Aniruddha Adak, an AI agent engineer and full stack developer from Kolkata, reported an exceptionally productive August in open source, opening 116 pull requests, filing 177 issues, and having 13 pull requests merged, five of which were into other people's repositories. A notable contribution was a fix to the genspark-ai/genoffice office suite, improving search functionality in large spreadsheets by reusing existing lazy-search primitives, which was praised by the maintainer.

Every month I tell myself I will take it easy. Every month the exact opposite happens. August was supposed to be a calm final-year-college month between deadlines. Instead it turned into the busiest open source stretch of my life so far. I opened 116 pull requests, filed 177 issues, watched five of my external pull requests get merged by maintainers, and built an entire hackathon project in a single day. I am Aniruddha Adak, an AI agent engineer and full stack developer from Kolkata, and this is my honest, complete, numbers-verified recap of August 2026. No inflated claims. Every number below came straight out of the GitHub API. If you have ever wondered what it actually looks like when one person treats open source like a daily practice, pull up a chair. Before the stories, here is the raw scoreboard for August, pulled directly from GitHub's search API on the last day of the month. bash $ august --recap --author aniruddhaadak80 pull requests opened ............ 116 pull requests merged ............ 13 merged into other people's repos 5 gracefully withdrawn by me ...... 8 still open and healthy .......... 75 issues filed .................... 177 public security reports ......... 7 one project alone private security advisories ..... 2 in maintainer triage hackathon projects built ........ 1 in one day articles published .............. 2 counting this one When I first ran that query and saw 177, I assumed I had double counted something. I had not. It turns out that when you spend your evenings reading other people's codebases with a magnifying glass, the bugs start lining up like customers at a Kolkata street food stall. Here is how those 177 issues spread across ten of the projects I audited. openclaw/openclaw ............... 60 google-gemini/gemini-cli ........ 40 langfuse/langfuse ............... 10 truefoundry/trueforge ........... 9 OpenHands/OpenHands ............. 9 volcengine/OpenViking ........... 8 PrimeIntellect-ai/prime-agent ... 8 langgenius/dify ................. 7 genspark-ai/genoffice ........... 5 Aider-AI/aider .................. 5 Now let me walk through the parts I am actually proud of, because numbers without stories are just spreadsheets. Every number above is one API call away if you want to verify it yourself on my GitHub profile https://github.com/aniruddhaadak80 . The biggest emotional win of the month came from genspark-ai/genoffice, an ambitious office suite project where the maintainer merrick-2002 has become one of my favorite people on the internet. The first fix started as an innocent question. On streamed, lazy-loaded workbooks, pressing Ctrl+F only searched the rows already loaded into the grid. If your spreadsheet had fifty thousand rows and you searched for a value sitting on row forty thousand, the Find dialog would cheerfully inform you that your data did not exist. It did exist. The dialog just never looked that far down. My fix registered a wrapper find provider that extends every search beyond the loaded window by paging data straight from the underlying file, reusing the same primitives the AI side already used for its own searches. When you click an out-of-window match, the sheet activates, the range loads, and the view scrolls to the real cell instead of a blank void. Replace All now honestly reports formula hits it cannot replace instead of silently skipping them. The part that made me happiest: I did not invent a parallel search path. I reused the lazy-search helpers the codebase already trusted, which is exactly what a good guest in someone else's house should do. merrick-2002 merged it within hours and left a comment that I have re-read more times than I would like to admit. He thanked me for the thorough write-up and specifically called out the care taken to reuse the AI-side lazy-search primitives and the edit-journal overlay instead of building something separate. For an open source contributor, that sentence is better than cake. IFindReplaceService : the built-in sheets model keeps owning everything inside the loaded window including its canvas highlights , while the wrapper extends each session with out-of-window matches paged from the underlying file via readSheetRangeMapped — session journal edits included, coordinates already covered by the loaded window excluded. Focusing an out-of-window match activates its sheet, starts loading its range ensureLazyRangeLoaded , scrolls to it, and selects it, so the grid shows real data instead of jumping to a blank region. Replace All reports out-of-window formula hits as failures instead of silently skipping them, consistent with the existing guard that blocks bulk replaces until the workbook is fully loaded. When a scan hits the budget or indexing lag, a status message says results may be incomplete new appFindScanTruncated string, all 19 locales . findInLazyWorkbook already pages the underlying file for exactly this reason; this brings the UI dialog to parity using the same primitives readSheetRangeMapped , ensureLazyRangeLoaded and the same budgets FILE READ BATCH CELLS , MAX SCAN CELLS , now exported from ai/workbook-search.ts .Implementation notes: registerFindReplaceProvider ; no prototype patching of Univer internals. The wrapper re-adopts whichever sheets provider is registered, so it survives workbook switches, and delegates unchanged for demo/fully-preloaded workbooks. hitCell . getMatches , so as regions stream in or evict, counts stay correct and navigation hands back to the native model once a jumped-to cell is materialized the inner model re-runs on mutations . apps/sheets/src/renderer/lazy-find.ts pure helpers exported for tests wired from the App mount effect; two new direct deps already present transitively: @univerjs/find-replace , rxjs .Known limitations deliberate scope cuts, happy to iterate : Closes 113 npm run format:check npm run lint — scoped ESLint run over all changed files: 0 errors the 3 pre-existing react-hooks/exhaustive-deps warnings in App.tsx's untouched cleanup block remain warnings npm run typecheck npm test — new suite apps/sheets/tests/lazy-find.test.ts 20 tests passes, and the rest of the sheets suite passes except tests that require the Rust sidecar binary / long perf timeouts, which cannot run on this Windows machine no MSVC toolchain for the cargo build; see below . Those code paths are untouched by this PR and are exercised by CI's Ubuntu job, which builds the sidecar before running vitest.List any checks not run and explain why: xlsx-sidecar , xlsx-recalc , xlsx-streaming-save , one xlsx-borders case fail locally with ENOENT ...xlsx-sidecar.exe because building the Rust sidecar here requires MSVC Build Tools that are not installed; cargo build fails at the linker step. No Rust code is modified by this PR, and CI builds the sidecar before running the suite. npm run licenses passes the two newly declared deps were already in the tree and allowlisted .Manual verification path for reviewers without a large fixture handy: open any .xlsx big enough to stream ~10k cells works , do not scroll, press Ctrl+F, and search for text that exists far below row 0 — before this PR it reports no matches; after, the count appears and Enter jumps to and selects the real cell. Not applicable — no visible chrome changes; the difference is the Find dialog's match count/jump behavior on large streamed workbooks. appFindScanTruncated added to all 19 locale blocks in strings-app.ts .The second merge was a feature rather than a fix. Cross-highlighting now draws soft highlights across the active cell's entire row and column, following the exact float-DOM patterns established by existing features like page-break preview and trace arrows, with theme tokens defined properly in all three theme blocks. This one also taught me a painful lesson in the most gentle way possible. In my first push, the three new i18n keys had their values shifted by one position across all nineteen locale blocks, so the View tab button literally rendered the text "en" or "zh" depending on language. merrick caught it instantly and explained precisely what had moved where. I fixed the shift, rebased onto the freshly-landed Ctrl+F change, and he merged it the next morning. Lesson learned and permanently installed in my workflow: after any bulk i18n edit, diff every locale block against the key list before pushing. Nineteen locales do not forgive copy-paste drift. Implementation notes: getLastRow/getLastColumn fallback for demo workbooks , clamped to the same caps the page-break preview draws 20k rows / 2k columns so huge sheets cannot freeze the grid. SelectionChanged / ActiveSheetChanged , debounces moves 60 ms , and skips reinstallation when the active cell did not change; bands are disposed/re-added only when the cell actually moves. Everything tears down with the app's mount effect. --sheets-crosshair-bg / --sheets-crosshair-line tokens defined in all three blocks in styles.css :root , data-theme='dark' , and the prefers-color-scheme fallback , per the theming rules; the bands themselves only reference tokens no raw colors , and the layers are pass-through float DOM so clicks and edits land on the grid. appCrossHighlight , appCrossHighlightOn , appCrossHighlightOff added to all 19 locale blocks.Closes 112 npm run format:check npm run check:theme-colors — the only raw values added sit on token-definition lines npm run check:english-comments npm run lint — scoped ESLint run over all changed/new files: 0 errors npm run typecheck npm test — new suite apps/sheets/tests/cross-highlight.test.ts 5 tests passes alongside the existing page-break preview suiteList any checks not run and explain why: Not applicable — I could not capture Electron screenshots from this environment. Visual result when enabled: the active row shows a faint blue band across the full sheet width, the active column the same down its full height, both with a slightly stronger edge line toward the active cell; both adapt to dark mode via the new tokens. Reviewers can reproduce in one click from the View tab. kirodotdev/KiroCrew gave me my first three-way merge day. All three landed on August 24, each reviewed by the repository's multi-model AI review pipeline before human maintainers pressed the button. The one that matters most to real users fixed genuine data loss. Re-opening a file in the dashboard discarded any unsaved edits you had made to it. Not flagged, not warned. Just quietly replaced your work with the version from disk. My fix routed every open affordance through a single choke point that keeps the edited buffer alive and carries its saved baseline so the existing dirty-state banner can keep doing its job. The design review bot summarized it better than I could: a real user-reported data-loss bug fixed at the single point every open path routes through. Why no screenshot: the strip renders identically before and after — the change is what survives a re-open the buffer , not anything visible in a static frame. The one observable difference is a negative an edit no longer disappears , which a screenshot cannot show; the vitest cases pin it. Re-opening a file that is already open as a document tab silently discards its unsaved edits . A document tab's content field is the live editor buffer — MarkdownPanel writes edits back through onContentChange → patchTab { content } — but every file-open affordance file chips, tool lines, the Files tab, the file picker routes through handleFileOpen → openFile , which re-reads the file from disk and hands it to upsert . upsertInBucket merges onto an existing tab with a spread, so the disk bytes replaced the buffer. The edits were gone with no prompt and no undo; the close guard never fired because from the panel's perspective the buffer simply changed fixes 1441 . This is silent, unrecoverable data loss on a mainstream gesture: clicking any second affordance for a file you are editing reverts your work. Editors conventionally keep the live buffer when a document is re-opened the hook's own docstring already promises "opening a document that's already open focuses its tab instead of duplicating it" — the implementation just also replaced its content . Telling "the user edited this tab" apart from "the file changed on disk" needs a baseline, so each file tab now carries one: PanelTab.savedContent records the on-disk bytes the buffer last matched. openFile compares the existing tab's buffer against that baseline. Dirty → upsert a patch that omits content / savedContent , so the spread refreshes everything around the buffer focus, reveal target, slot, diff-mode preference and keeps the text. Clean → take the fresh disk bytes and restamp the baseline, exactly as before. handleFileSave , cold-tab hydration success onDiskContent callback that the side panel wires to a content+baseline patch. The panel also receives savedBaseline={tab.savedContent} so its dirty guard computes from the same truth. serializeBucket strips savedContent along with content : the baseline mirrors a file body "can be MBs" , so persisting it would re-create exactly the localStorage-quota problem the strip exists to prevent. A restored tab without a baseline is dirty-by-default until hydration re-establishes both.Alternatives considered: preserving the buffer unconditionally on every re-open needs no new state but makes re-open useless as an external-change refresh for clean tabs; keying off content == diskBytes alone cannot distinguish an edited buffer from a stale one and would freeze stale buffers in place. The baseline gives both cases their right answer, and the panel already enforces the same contract elsewhere — its own Refresh control is disabled while dirty "save or discard changes first" . Six cases in website/src/test/usePanelTabs.test.ts : content + savedContent patched together re-arms refresh-on-reopen. content nor savedContent , while path survives.The pre-existing dedupe test "same path merges fresh content" still passes unchanged — it describes the clean path, which keeps its behaviour. Windows 11 / Node 22: cd website npx vitest run src/test/usePanelTabs.test.ts src/test/MarkdownPanel.test.tsx → 69 passed npm run typecheck → clean npx eslint <five changed files → 0 errors; warning count at the repo's pinned ceiling The full frontend suite npm run check exceeds this machine's local time budget; CI runs it authoritatively on this PR. N/A — see the no-visual-delta marker above. Fixes 1441 fix: ... The second merge deleted code, which is my favorite kind of contribution. A port allocation helper existed solely to work around a tunnel constraint that a previous pull request had already removed. Its own docstring admitted it could simply pass the registry default. I removed the helper, pointed both call sites at their own defaults, and rewrote the test suite so that anyone who reintroduces allocation gets a red build instead of a shrug. Deletion is underrated. Every dead workaround you remove is a small gift to the next reader. RealLaunchEngine. allocate port exists only to work around a constraint that no longer exists. It was written because the instance tunnel forced local port == remote port and hard-failed when that port was busy, so a cloud crew registered on the default dashboard port could never be connected. 5189 removed that constraint — the hub now allocates its local forward port independently — and the helper's own docstring conceded it "could simply pass the registry default". The deletion was asked for three times in 5189's First Principles review and deferred there only on blast-radius grounds fixes 5253 . Leaving it costs every future launch a fresh, pointless port allocation on both ends of one crew, keeps an instances-registry read on the cloud provisioning path for information the registry no longer needs, and forces every reader to reconstruct the dead local==remote rule to understand two lines of kwargs. The hedge "still mildly useful" is not a requirement; this makes the removal owned. With the tunnel's local port independent, a crew no longer needs a unique remote port: EC2 hosts are isolated per crew, so sharing the stock remote port cannot collide across crews, and within one host there is exactly one gateway. Both ends therefore take their own defaults, which already agree: provision calls ec2.deploy ... with dashboard port override → the CloudFormation stack binds its DashboardPort default 5476 , per cloud/templates/kirocrew-ec2.yaml . register calls register instance ... with remote port → its signature default DEFAULT REMOTE DASHBOARD PORT = 5476 cloud/connect.py , the same number. allocate port , the memoised self. port , and the now-unused PortAllocator / InstancesRegistry imports are deleted.Alternatives: keeping the helper "just in case" was the exact state being corrected; making the default explicit by passing constants at both call sites would duplicate two spellings of one fact instead of deleting them. TestRealEngineGatewayPort in test/test cloud launch job.py is rewritten to pin the new contract: after provision + register, ec2.deploy received no dashboard port key and register instance received no remote port key — so any reintroduced allocation step turns the suite red. The three tests that existed to pin the old allocation behaviour same port both ends, skip registry ports, survive an unreadable registry are deleted along with the behaviour they described. Full local run of the touched surface, Windows 11 / Python 3.12: pytest test/test cloud launch job.py test/test cloud cli.py test/test cloud wizard.py \ test/test cloud login.py test/test cloud connect.py → 142 passed, 3 skipped Plus flake8, isort, mypy clean on the changed module. Both changed files sit in .github/black-baseline.txt ; their pre-existing formatting state is untouched and the diff adds no new black findings. Fixes 5253 refactor: ... The third merge un-skipped an entire test suite on Windows. The Code Review Sage tests were gated off behind a blanket operating-system check, even though most of them run perfectly well on Windows once you guard the specific tests that genuinely need Unix symlinks. Blanket skip replaced with cause-specific guards, measured results included. Code Review Sage's test suite is collected nowhere on Windows: tests/conftest.py sets collect ignore glob = " " for the whole directory, so the platform the app is being brought up on has zero automated coverage of it 4988 . The gate predates the app's Windows support work and conflates the app-level refusal in sage lib/discovery.py 's gh bin its review prompts still name python3 — untouched here, tracked separately with three harness details the tests themselves can express. The coverage hole sits exactly where recent risk was: a Windows-only silent failure in the review worker had to be found by hand because no Windows shard ran a single sage test. Every PR that touches this app lands blind on the platform it now claims to support. Lift the collection gate and give each platform-dependent test the guard its failure actually needs, instead of one blanket skip: OSError: WinError 1314 . SYMLINKS OK , a probe for unprivileged symlink creation, defined privately in test followup.py . That probe now lives in tests/fixtures.py , the suite's shared module, and every test that stages a planted link skips only where creating a symlink needs a privilege the host does not grant Developer Mode / elevated runners run them again . The no-follow guards they pin keep running everywhere else. 0600 through st mode , which Windows never reports the lockdown there is an ACL . That assertion is scoped to POSIX while file-presence and temp-file-cleanup checks still run on every platform; the two existing skipUnless platform compat.IS POSIX sites are unchanged.Alternatives weighed: keeping the blanket gate until 4979 lands leaves the coverage hole open longer , or making the mode assertions ACL-aware instead of POSIX-gated no cross-platform "verify owner-only DACL" helper exists yet; that would be a new production-side seam, out of scope for a test-enablement change . Test-only change; the diff modifies how tests are gated, not what they assert: @unittest.skipUnless SYMLINKS OK, ... with the suite's established reason string. test outputs are private and leave no temp behind pins its 0600 assertion behind platform compat.IS POSIX and keeps presence/cleanup assertions unconditional. test followup.py imports the shared probe instead of defining its own copy same semantics, one owner .Measured locally on Windows 11 Python 3.12, the CI pin set: pytest 9.0.3 / xdist 3.5.0 / pytest-timeout 2.2.0 : | run | before | after | |---|---|---| serial -n0 | 21 failed / 735 passed / 11 skipped | 736 passed / 31 skipped / 0 failed | parallel -n4 --dist loadgroup | — | 736 passed / 31 skipped / 0 failed | Gates: flake8 clean, isort --check-only clean, mypy clean over the suite's 30 files, git diff --check clean. The five touched files sit in .github/black-baseline.txt ; their formatting state is unchanged and the diff adds no new black findings. N/A for browser/UI checks — nothing user-visible moves. Fixes 4988 test: ... KiroCrew also taught me patience the hard way. Another PR of mine there spent the month trapped in the first-contribution workflow-approval pattern where checks refuse to run until a maintainer clicks approve. During one squash operation, a transient empty-branch window caused an automation to auto-close my pull request entirely. I reopened it, squashed to exactly one commit per their gate, stripped a stray byte-order mark from the description, annotated synthetic AWS key literals for the SAST scanner, and posted an explanation comment. It is watching CI as I write this. Fingers crossed, politely. This section is about something rarer than merges. Three of my bug fixes in NousResearch/hermes-agent landed through salvage pull requests opened by the maintainer himself, with my authorship explicitly preserved and credited. The fixes themselves were fun. One stopped install.ps1 from crashing at line 367 on fresh Windows machines whenever PowerShell StrictMode was enabled, because a variable was only initialized on a rare short-path branch. One made two test files stop failing when run together, thanks to a truncation-warning context variable leaking state between them. One stopped short sessions from permanently disabling auto-compaction, because structural no-op compressions were being counted as ineffective strikes until a breaker latched for the whole session and context ballooned forever after. What made the week special was seeing my handle appear in the merge commits as co-author. Salvage culture, when done right, is one of the healthiest things in open source. Your fix lands, the original author keeps credit, nobody's work evaporates in a closed pull request. I will happily be salvaged again. install.ps1 no longer crashes at line 367 on fresh Windows installs when the caller's PowerShell session has StrictMode enabled. $script:LastResolver was only assigned on the rare 8.3-short-path branch; every ordinary machine reached the resolved-path report with the variable unset → fatal InvalidOperation before any install stage ran. Salvage of 93020 by @liuhao1024 first-filed, primary credit; authorship preserved + the 'skipped-long-path' diagnostics hunk from 93100 Co-authored-by: @aniruddhaadak80 . Closes 93017. scripts/install.ps1 : initialize $script:LastResolver = 'none' before the report; early long-path return now records 'skipped-long-path' so the report distinguishes "skipped" from "never ran" tests/test install ps1 resolver strictmode.py : 3 source-contract tests init exists, init precedes resolver-run and report-read, early-return pinned | Before main | After branch | | |---|---|---| pwsh 7.4.6 StrictMode, -ShowResolvedPaths | InvalidOperation at install.ps1:367, exit 1 | clean JSON report, "resolver":"skipped-long-path" , exit 0 | | contract tests vs base install.ps1 | 2 failed, 1 passed | 3 passed | Live repro on real PowerShell portable 7.4.6 , not simulated. Auto-compaction no longer disables itself permanently on sessions that start too short to compress. The anti-thrash breaker counted structural no-ops insufficient messages , no compressible window , empty post handoff window as ineffective-compression strikes; two such no-ops latched the ≥2 breaker for the life of the session, so compaction never ran even after the session grew — context ballooned and every turn got more expensive. Salvage of 93093 by @aniruddhaadak80 authorship preserved . Closes 93022. agent/context compressor.py : structural no-ops arm a transient in-memory 300s backoff structural backoff:<s block reason instead of durable strikes; cleared on /compress force , completed compaction, and session reset. Genuine attempted-but-underperformed verdicts still strike. test context compressor structural backoff.py + 4 existing anti-thrash test files aligned to the new contract| Before main | After branch | | |---|---|---| | 2 compress calls on 5-msg session | strikes 1→2, breaker latched ineffective | strikes stay 0, backoff armed | | Session grown to 45 msgs w/ compressible material | still blocked forever | eligible again after backoff elapses | /compress force | n/a | bypasses backoff verified | | PR test files 5 | — | 40 passed | Preserves 40803's anti-refire guarantee same 300s cadence as the existing recovery probe . Note: overlaps open 88388 insufficient messages prune-first — that PR will need a small rebase of one hunk if salvaged later. Meanwhile two of my other hermes pull requests went green this month after stale-bot scares, twenty-two tests passing with zero failures, and both are now sitting pretty awaiting review. Slow queues are still queues. On August 24, the Agent Harness Hackathon by WeMakeDevs, TrueFoundry, and Qodo kicked off. I decided to build my submission, RepoMedic, in a single focused day, using agentic workflows to do the heavy lifting while I steered. RepoMedic is an autonomous open-source repository triage agent built on TrueForge. It scans repositories for real problems such as failing CI, broken README links, stale issues, and vulnerable dependencies. It investigates each finding in a sandboxed environment with parallel subagents, and then does the thing most agents are too brave about: it stops and asks a human before anything irreversible. Read-only scans run free. Every write action, whether filing an issue, posting a comment, or opening a pull request, pauses at an approval gate until you choose allow or deny. It ships with a custom MCP server exposing repo health tools, retry logic with backoff for flaky GitHub API calls, production middleware, a designed landing page, community health files, a judges runbook, and CI typechecking. Eight pull requests merged into the repository in one day, which felt appropriately meta: an agent-harness hackathon entry assembled by a human-with-agents harness. An autonomous open-source repository triage agent, built on TrueForge — the open-source agent harness — forThe Agent Harness Hackathon WeMakeDevs × TrueFoundry × Qodo, Aug 24–30 2026 . RepoMedic is the maintenance agent every maintainer wishes they had: it scans your repositories for real problems — failing CI, broken links in the README, stale issues, vulnerable dependencies — investigates each one in a sandboxed environment with parallel subagents, and then stops and asks a human before anything irreversible : no issue is filed, no comment posted, no PR opened until you approve it in the chat. ┌─────────────┐ MCP ┌──────────────────┐ approval gate ┌─────────┐ │ You chat │◄──────────►│ TrueForge harness│◄── Allow / Deny ─►│ GitHub │ └─────────────┘ │ · model loop │ └─────────┘ │ · subagents │ read-only scans run free │ · sandbox runs │ every write pauses for you └──────────────────┘ | Capability | How RepoMedic uses it | |---|---| Real MCP | The philosophy underneath is the part I care about most. Autonomy is not the absence of humans. The best autonomous systems know exactly where the line is between safe exploration and irreversible action, and they treat that line like a load-bearing wall. Filing good bug reports is a skill nobody teaches. Each of my 177 reports this month followed the same recipe: reproduce it locally, isolate the root cause in the source, explain the mechanism precisely, propose a fix direction, and be polite about all of it. Maintainers can smell the difference between a drive-by "this is broken" and a report that respects their time. A few favorites from the haul, each verified with a local reproduction before filing. In google-gemini/gemini-cli I found a security issue where the project .env file can inject execution-affecting git environment variables such as GIT EXEC PATH and GIT SSH COMMAND into internal git operations, because sanitization only strips GIT CONFIG variables. I also found grounding citation markers being inserted at wrong positions because UTF-8 byte offsets were spliced into UTF-16 strings, and a case-sensitive path containment check rejecting valid in-root paths over drive-letter casing on Windows. Gemini CLI loads a project's .env file into process.env at startup trusted workspaces load all keys , and its internal git operations are executed with an environment derived from process.env . The git-environment hardening that does exist getSafeGitEnv in packages/core/src/utils/gitUtils.ts , sanitizeEnvironment usage in packages/core/src/services/gitService.ts , and the equivalent logic in shellExecutionService.prepareExecution only neutralizes GIT CONFIG / GIT CONFIG PARAMETERS . It does not touch the other GIT variables that change which binaries and helpers git executes . As a result, a malicious-but-trusted repository can ship a .env containing, for example: GIT EXEC PATH=C:\Users\victim\AppData\Local\Temp\evil GIT SSH COMMAND=calc.exe GIT PROXY COMMAND=cmd /c calc.exe and, merely by starting Gemini CLI inside that repository folder-trusted, e.g. once via the trust prompt or when folder trust is disabled , trigger attacker-controlled code through completely ordinary, non-model, pre-approval git calls such as: GitService.initialize → spawnAsync 'git', '--version' , { env: getSafeGitEnv } and subsequent shadow-repo commits git resolves subcommand binaries from GIT EXEC PATH ; core.hooksPath is already neutralized, but these env vectors are not cloneFromGit uses simple-git with getSafeGitEnv , where git.fetch / clone will invoke GIT SSH COMMAND / GIT PROXY COMMAND for non-https remotes getAbsoluteGitDir The codebase demonstrates awareness of this exact risk class: DEFAULT EXCLUDED ENV VARS blocks GEMINI CLI IDE SERVER STDIO COMMAND / ARGS from project env files precisely because they name executables — but no equivalent protection exists for git's executable/helper env vars. Environment sanitization for internal git invocations should also strip or pin execution-affecting variables, e.g.: getSafeGitEnv and the parallel logic in gitService.getShadowRepoEnv / shellExecutionService.prepareExecution : delete GIT EXEC PATH , GIT PROXY COMMAND , GIT SSH COMMAND , GIT SSH VARIANT , GIT ALTERNATE OBJECT DIRECTORIES , GIT TEMPLATE DIR , GIT REPLACE REF BASE , GIT CEILING DIRECTORIES as applicable , rather than only GIT CONFIG . DEFAULT EXCLUDED ENV VARS so project .env files cannot introduce these variables at all.This restores the same isolation intent that already exists for git config credential.helper, core.hooksPath, etc. but which currently stops one layer short. Source-level finding verified against upstream main at commit 5411f113c . All platforms; requires a trusted workspace whose .env sets the offending variables untrusted workspaces are protected because loadEnvironment whitelists only GEMINI API KEY , GOOGLE API KEY , GOOGLE CLOUD PROJECT , GOOGLE CLOUD LOCATION . Not applicable. Sources: packages/cli/src/config/settings.ts:693-726 — trusted workspace .env values are loaded into process.env unless in DEFAULT EXCLUDED ENV VARS packages/cli/src/config/settings.ts:82-87 — DEFAULT EXCLUDED ENV VARS contains only 4 entries; no GIT packages/core/src/utils/gitUtils.ts:9-45 — getSafeGitEnv strips only GIT CONFIG / GIT CONFIG PARAMETERS packages/core/src/services/gitService.ts:102-124 — shadow-repo env built from sanitized process.env ; execution-affecting GIT survive packages/cli/src/config/extensions/github.ts:37 — extension clones run with getSafeGitEnv In langfuse I found the legacy ingestion pipeline overwriting an explicit usage.total of zero because of JavaScript truthiness, a classic where the value zero falls through a fallback check it should satisfy. The fix direction is a one-token change from the loose or operator to nullish coalescing, and yes, I filed it with the exact worker lines cited. In the legacy ingestion path, when usage.total is explicitly provided as 0 , the || operator treats it as falsy and overwrites it with a computed total derived from input + output . This silently corrupts the stored usage data. worker/src/services/IngestionService/index.ts , lines 1924-1932: js const newTotalCount = "usage" in obs.body ? obs.body.usage?.total : undefined || Object.keys "usageDetails" in obs.body ? obs.body.usageDetails ?? {} : {}, .length === 0 ? newInputCount && newOutputCount ? newInputCount + newOutputCount : newInputCount ?? newOutputCount : undefined ; Send an ingestion event with: { "type": "generation-create", "id": "...", "traceId": "...", "usage": { "input": 100, "output": 50, "total": 0 } } Expected: provided usage details.total = 0 the caller explicitly stated 0 tokens Actual: provided usage details.total = 150 computed from input + output because 0 || ... is falsy JavaScript's || operator short-circuits on any falsy value, including 0 , false , and "" . Since usage.total can legitimately be 0 e.g., cached responses where no tokens are counted, or when the caller intentionally reports 0 , the || should be replaced with ?? nullish coalescing which only short-circuits on null or undefined . provided usage details.total and usage details.total will be wrong for any SDK that sends total: 0 Note: the newInputCount && newOutputCount expression on line 1929 has a similar issue -- if input: 0 is sent without output , the expression evaluates to 0 falsy and falls through to newInputCount ?? newOutputCount . However, this branch only executes when total is not provided AND usageDetails is empty, so it is a less likely scenario. The primary bug is the usage.total overwriting. Replace || with ?? on line 1925: js const newTotalCount = "usage" in obs.body ? obs.body.usage?.total : undefined ?? Object.keys "usageDetails" in obs.body ? obs.body.usageDetails ?? {} : {}, .length === 0 ? newInputCount && newOutputCount ? newInputCount + newOutputCount : newInputCount ?? newOutputCount : undefined ; This preserves explicit 0 values while still falling through to the computed total when total is undefined or null . || is used on numeric usage fields -- check if newInputCount or newOutputCount have the same truthiness issue elsewhere in the merge step newInputCount && newOutputCount fallback line 1929 should also be fixed -- 0 && ... evaluates to 0 which is falsy, so it falls through to ?? . This is technically correct for the fallback path but may warrant explicit = null checks for clarity total: 0 -- if none do, this is a latent bug waiting to happen rather than an actively exploited oneIn dify I reported that JWT validation accepts trailing whitespace, which turns a strict token comparison into something fuzzier than anyone intended. In volcengine/OpenViking I documented zip extraction paths with no decompression-bomb guard, where a crafted archive can fill a disk through otherwise legitimate-looking flows. In PrimeIntellect-ai/prime-agent, execCommand accumulates child process output without any cap, so a chatty command can OOM-crash the whole agent mid-task. Seven of my dify findings were pure security reports: SSRF in the website crawling service, verbose internal error leakage, a race condition in crawl status polling, insecure pickle deserialization in dataset embeddings, missing authorization on internal API endpoints, incomplete markdown sanitization, and the JWT whitespace bypass above. Two more advisories went through GitHub's private vulnerability reporting for another project and are currently sitting in maintainer triage, so details stay sealed for now. Responsible disclosure means the fun details wait their turn. One pull request deserves its own story. While working in langfuse, Greptile's review bot flagged a P1 concern on my mention-sanitization pull request: the lazy display-name capture could span past a malformed mention's failed delimiter and swallow a following valid mention, silently deleting text in between. I reproduced it with a standalone Node script, confirmed the bot was right, and then made it worse before making it better. My first fix applied the lookahead once rather than per character, which still allowed the capture to cross the boundary in edge cases. The corrected pattern uses a tempered group, where every character step re-checks that we have not entered a malformed mention boundary. The shape of the problem is easiest to see on a tiny input. js const BODY = "see Alice user:7 then Bo u then Cara user:9 "; const MENTION = /\ ^\ {1,100}\ \ user:\d+\ /g; BODY.match MENTION ; // " Alice user:7 ", " Cara user:9 " A malformed middle mention must act like a wall, not a trampoline. The corrected pattern uses a tempered group, where every character step re-checks one small guard condition before moving forward, so the lazy capture physically cannot step across a broken delimiter and swallow the next valid mention. One extra check per character, and silent text deletion becomes impossible. Sixty-one parser tests passed locally, the worker copy got the identical treatment with reasoning documented for why its slightly looser userId pattern stays cosmetic-safe, and the whole exchange ended with me thanking the review bot for catching what I missed. Reviewing the reviewer sounds recursive until the day it saves you. @-mentions in comments are silently dropped when the mentioned user's display name contains square brackets, e.g. John Doe Platform Team a common SSO/IdP display-name format . The mention UI inserts the raw name into the token: @ John Doe Platform Team user:cmr9klx3v0005434tzy5d86dq but MENTION REGEX in web/src/features/comments/lib/mentionParser.ts captured display names with ^ \ {1,100} , which can never match a bracketed name. Result: extractUniqueMentionedUserIds returns nothing, validMentionedUserIds ends up empty, and no COMMENT MENTION job is enqueued — no email, no log line, nothing. The worker's email-preview stripping @\ ^\ + \ \ user: ^ +\ had the same bracket-hostile pattern. Fixes 14836 The userId — not the display name — is the authoritative part of a mention, so both patterns now anchor a bounded lazy capture on the literal user: suffix instead of excluding brackets from the name: @\ .{1,100}? \ \ user: a-z0-9 - {1,30} \ buildCommentPreview same file, no behavior change beyond the regex so it can be unit-tested directly. web/src/features/comments/lib/mentionParser.clienttest.ts : flipped the two cases that codified the old bracket-hostile behavior "nested brackets" now match; "many repeated brackets" resolves to the mention's user , and added positive extract + sanitize coverage for names like Jane Doe Platform Team . pnpm --filter web run test-client src/features/comments/lib/mentionParser.clienttest.ts → worker/src/ tests /comment-mention-preview.test.ts covering regular names, bracketed names, truncation and plain text. pnpm --filter worker run test src/ tests /comment-mention-preview.test.ts → pnpm --filter web run typecheck → exit 0; prettier applied to every changed file. MarkdownViewer ; bracketed names already degraded to plain text there before this change and continue to do so. This PR restores notifications the reported bug without touching the renderer. @ Alice user:alice123 now resolves to the mention's user previously ignored . I'd argue that is correct under "userId is authoritative" — the sanitizer rewrites it to the canonical name — but it is a deliberate behavior change called out by an updated test.This PR broadens comment-mention parsing and email-preview formatting to support display names containing square brackets, and adds focused parser and worker tests. buildCommentPreview into an exported helper and tests bracketed names and truncation.The PR should not merge until mention matching is prevented from consuming and deleting text across malformed token boundaries. The new lazy display-name capture can expand past an invalid mention suffix into a later valid mention, after which sanitization replaces the entire merged span and persists the resulting loss of user-authored content. Files Needing Attention: web/src/features/comments/lib/mentionParser.ts sequenceDiagram participant U as Comment author participant W as Web comment router participant P as Mention parser participant DB as Postgres participant Q as Notification queue participant N as Worker U- W: Submit comment content W- P: Extract and sanitize mentions P-- W: Sanitized content and valid user IDs W- DB: Persist sanitized comment W- Q: Enqueue COMMENT MENTION Q- N: Process notification N- DB: Re-fetch comment and membership N- N: Build email preview N-- U: Send mention email Issue 1 web/src/features/comments/lib/mentionParser.ts:22 Mention matching crosses token boundaries When a malformed mention with an invalid user ID precedes a valid mention within 100 characters, the lazy display-name capture expands through the later token and sanitizeMentions replaces the entire merged span, silently deleting intervening user-authored text from the persisted comment. --- For each issue above, determine whether it is valid and should be fixed. If so, fix it directly. Reviews 1 : Last reviewed commit: "fix comments : parse mentions whose disp..." https://github.com/langfuse/langfuse/commit/a3db92c50020a8c8a1d95bcc33b20efe341c170a | Re-trigger Greptile https://app.greptile.com/api/retrigger?id=56028328 Greptile also left 1 inline commenton this PR. Context used: That same session produced three langfuse issue filings, each posted with an explicit note inviting reviewer doubt, because confidence without invitation to correct is just noise. Not every contribution is a shiny merge. A large slice of my August went into maintaining the health of roughly 157 open pull requests across fifteen tracked repositories. One dedicated pass triaged 146 of them in a single sweep. Conflicts on a long-running openclaw pull request got resolved through low-level git plumbing after ordinary checkout proved too slow for the giant worktree on my machine, and the rebased head went back green into a queue of 106 checks. A genoffice e2e failure turned out to be a worker-teardown timeout flake, diagnosed, proven with a rerun, and confirmed green four minutes later. Stale-bot notices were answered. CLAs were signed. Duplicate pull requests of mine were closed by me with thank-you notes to reviewers, including one where upstream had implemented the idea faster than I could land it. Closing your own superseded pull request quickly and kindly is a contribution too. It clears the maintainer's queue and signals that you read upstream before insisting on your own patch. Some waits continue. Four Pomodoro-Timer pull requests sit mergeable and untouched. Around thirty lobehub pull requests show failing Vercel deployments purely because fork deployments need authorization the maintainers must grant, a limitation I verified carefully so nobody wastes time debugging phantom code failures. Patience is part of the craft. August also included a stranger kind of productivity. I run orchestrated agent workflows daily, and this month I pointed that machinery at myself. Four parallel research tracks crawled every website I have ever deployed, mapped every social account, queried the GitHub API for ground-truth contribution numbers, and hunted third-party mentions of my name. The audit found dead domains, template-invented testimonials living on generated portfolio sites, and a senior executive at a housing finance company who shares my name and confuses AI answer engines. The result became a long-form post draft, a permanent memory file that every future agent session now reads before acting for me, and a cleanup checklist I am steadily executing. There is something beautifully circular about an AI agent engineer getting his own digital footprint forensically audited by AI agents he configured. I also published a submission for DEV's Summer Bug Smash powered by Sentry, walking through one frantic day of fixing three real bugs across three projects, each shipped with a failing-first test. That article is right here on DEV if you want the play-by-play. First, small reproductions beat big arguments. Every single accepted fix and confirmed issue this month started as a script or command that made the bug happen on demand. Opinion invites debate. Reproduction invites action. Second, conventions are a love language. The merges that landed fastest were the ones where I matched the project's existing patterns, filled out their exact pull request templates, and split helpers the way their reviewers like to read. The one i18n slip that slipped through happened precisely where I rushed the project's bulk-edit conventions. Third, deletion and restraint count as contributions. Removing a dead helper, refusing to parallel-path around existing primitives, gating write actions behind human approval in RepoMedic, dropping my own duplicate pull requests gracefully. Open source rewards people who make codebases smaller and calmer, not just bigger. Fourth, security eyes pay rent everywhere. Once you start asking "what if this field contains a URL" or "what if this number is zero" or "what if this string ends with a space", you find seven vulnerabilities in an afternoon. Most of them were not exotic. They were ordinary questions asked persistently. The langfuse pull requests await maintainer CI approval and review, and I will shepherd them patiently. OmniRoute, an AI gateway with hundreds of providers and remarkable velocity, tops my discovery queue as the next fork-and-contribute target. MiMo-Code got its first pull request from me in the last hours of August, a recovery fix so a failed session load lands you on home instead of a black screen, and follow-ups are queued. RepoMedic enters judging week. And the daily hygiene rotation continues, because 157 open pull requests do not babysit themselves. If any of this resonated, here is my standing advice. Pick one thing that annoys you in software you use, shrink the problem until it fits on one screen, prove it with a test, and send the fix with a polite description. Maintainable, humble, reproducible contributions get merged. I watched it happen thirteen times this month, and five of those times it happened in somebody else's repository, which is the part that still feels like magic. Thank you to merrick-2002, iamwhatever, chenmingwei23, bolichen97, teknium1, and every maintainer who reviewed, approved workflows, merged, or simply kept their issue tracker welcoming enough that a college student from Kolkata wanted to keep showing up. You make the whole thing work. See you in the September recap. I have already warned my keyboard.