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.
The Scoreboard First, Because Numbers Are Fun
Before the stories, here is the raw scoreboard for August, pulled directly from GitHub's search API on the last day of the month.
$ 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.
Two Merges in GenOffice, Including One I Am Genuinely Proud Of
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.
fix(sheets): extend Ctrl+F beyond the loaded window on streamed workbooks
#131
-
What changed? On streamed (lazy-loaded) workbooks, the Find dialog now searches the whole sheet instead of only the rows already loaded into Univer's grid. A wrapper find provider is registered with
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 viareadSheetRangeMapped— 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 (newappFindScanTruncatedstring, all 19 locales). -
Why is this change needed? The Find dialog iterates Univer's in-memory cell matrix, so on large lazy-loaded sheets every not-yet-streamed row was silently skipped: users searched for values that exist and got "no results", concluding the data does not exist. The AI-side
findInLazyWorkbookalready 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 fromai/workbook-search.ts).
Implementation notes:
- Uses Univer's public extension point (
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. - Matching mirrors the built-in semantics (substring vs whole-cell with space-only trimming, case sensitivity, formula-vs-value look-in); needles are lower-cased once up front like the built-in parser does. Formula hits are never value-replaced, mirroring
hitCell. - Out-of-window hits are deduped against the live inner list on every
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). - New module
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):
- Filtered-out rows are not excluded from out-of-window hits (the in-window scan still skips them natively).
- Extras refresh when a search starts; between searches only the inner list refreshes live.
- Replace on an unloaded plain-cell hit writes straight onto the cell; the edit journal replays it onto later viewport installs, so saves and AI reads stay correct.
Closes #113
- [x]
npm run format:check - [x]
npm run lint— scoped ESLint run over all changed files: 0 errors (the 3 pre-existingreact-hooks/exhaustive-depswarnings in App.tsx's untouched cleanup block remain warnings) - [x]
npm run typecheck - [x]
npm test— new suiteapps/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:
- Sidecar-dependent tests (
xlsx-sidecar,xlsx-recalc,xlsx-streaming-save, onexlsx-borderscase) fail locally withENOENT ...xlsx-sidecar.exebecause building the Rust sidecar here requires MSVC Build Tools that are not installed;cargo buildfails at the linker step. No Rust code is modified by this PR, and CI builds the sidecar before running the suite. -
npm run licensespasses (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.
- [x] The change is focused and does not include unrelated reformatting or refactoring.
- [x] User-facing strings use the existing i18n resources (
appFindScanTruncatedadded to all 19 locale blocks instrings-app.ts). - [x] File open/save changes include an appropriate round-trip or fidelity test. — N/A: nothing in the open/save paths is touched; replacements go through the existing edit journal that save already replays.
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.
feat(sheets): cross-highlight the active cell's row and column
#132
- What changed? GenOffice Sheets gains an opt-in "reading mode": a translucent band covers the active cell's entire row and another covers its column, tracking the selection as you navigate. It is toggled from the View tab's Show group ("Highlight active row & column", next to Gridlines/Headings), the choice persists in localStorage like the auto-save flag, and it is off by default.
- Why is this change needed? Feature request tracked in #112: while working in wide sheets, it is easy to lose track of which row/column a cell belongs to. Excel-style cross-highlighting of the active row and column fixes that at a glance.
Implementation notes:
- The bands are float-DOM layers anchored to ranges — the same mechanism the page-break preview and formula-audit traces use — so they follow scroll and zoom with no extra rendering work. Row/column extents come from the file-backed sheet extent under lazy streaming (with
getLastRow/getLastColumnfallback for demo workbooks), clamped to the same caps the page-break preview draws (20k rows / 2k columns) so huge sheets cannot freeze the grid. - A single installer subscribes to
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. - Styling goes through new
--sheets-crosshair-bg/--sheets-crosshair-linetokens defined in all three blocks instyles.css(:root,[data-theme='dark'], and theprefers-color-schemefallback), 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. - User-facing strings (
appCrossHighlight,appCrossHighlightOn,appCrossHighlightOff) added to all 19 locale blocks.
Closes #112
- [x]
npm run format:check - [x]
npm run check:theme-colors— the only raw values added sit on token-definition lines - [x]
npm run check:english-comments - [x]
npm run lint— scoped ESLint run over all changed/new files: 0 errors - [x]
npm run typecheck - [x]
npm test— new suiteapps/sheets/tests/cross-highlight.test.ts(5 tests) passes alongside the existing page-break preview suite
List any checks not run and explain why:
- The full sheets vitest suite was exercised on this machine earlier from an identical tree; tests that require the Rust sidecar binary cannot run locally here (no MSVC toolchain to link the cargo build). This PR touches renderer-only files and no Rust code; CI builds the sidecar before running the suite.
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.
- [x] The change is focused and does not include unrelated reformatting or refactoring.
- [x] User-facing strings use the existing i18n resources.
- [x] File open/save changes include an appropriate round-trip or fidelity test. — N/A: display-only feature; nothing touches the open/save paths.
The KiroCrew Hat Trick: Three Merges in One Project
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.
fix(dashboard): re-opening a file no longer discards its unsaved edits
#5384
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.savedContentrecords the on-disk bytes the buffer last matched. -
openFilecompares the existing tab's buffer against that baseline. Dirty → upsert a patch that omitscontent/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. - Every path that moves DISK truth into the buffer restamps the baseline in the same write: successful saves (
handleFileSave), cold-tab hydration (success and its error placeholder — an unreadable-file message is not unsaved work, so the next click retries the read instead of "protecting" it), and the two disk-originated panel paths (file watch and Refresh), which MarkdownPanel now routes through a new optionalonDiskContentcallback that the side panel wires to a content+baseline patch. The panel also receivessavedBaseline={tab.savedContent}so its dirty guard computes from the same truth. -
serializeBucketstripssavedContentalong withcontent: 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:
- Re-opening a path whose tab holds edits focuses the tab and keeps the buffer (baseline untouched).
- Re-opening a clean tab still refreshes content + baseline from disk.
- After a save stamps the baseline, a later open refreshes again.
- A buffered tab without a baseline is treated as dirty, not reverted.
- A disk-originated refresh (
content+savedContentpatched together) re-arms refresh-on-reopen. - Persistence stays metadata-only: the localStorage payload carries neither
contentnorsavedContent, whilepathsurvives.
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
- [x] Single commit with a Conventional Commits title (
fix: ...) - [x] Existing tests pass and new tests added for new functionality
- [x] Self-review completed; code follows project style guidelines
- [x] Documentation updated (if applicable) — N/A: no documented behaviour changes; the baseline contract is documented on the type and in place
- [x] No secrets, credentials, or internal references in the diff
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.
refactor(cloud): let a provisioned crew take the stock port
#5351
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()callsec2.deploy(...)with nodashboard_portoverride → the CloudFormation stack binds itsDashboardPortdefault (5476, percloud/templates/kirocrew-ec2.yaml). -
register()callsregister_instance(...)with noremote_port→ its signature defaultDEFAULT_REMOTE_DASHBOARD_PORT = 5476(cloud/connect.py), the same number. -
_allocate_port, the memoisedself._port, and the now-unusedPortAllocator/InstancesRegistryimports 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
- [x] Single commit with a Conventional Commits title (
refactor: ...) - [x] Existing tests pass and new tests added for new functionality
- [x] Self-review completed; code follows project style guidelines
- [x] Documentation updated (if applicable) — N/A: no documented behaviour changes; the helper's docstring left with it
- [x] No secrets, credentials, or internal references in the diff
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.
test(sage): run the Code Review Sage suite on Windows too
#5335
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:
-
Symlink plants (20 of 21 failures, all
OSError: [WinError 1314]). The suite already had the right pattern —SYMLINKS_OK, a probe for unprivileged symlink creation, defined privately intest_followup.py. That probe now lives intests/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. -
Owner-only mode bits. The report-output privacy test asserted
0600throughst_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 existingskipUnless(platform_compat.IS_POSIX)sites are unchanged. - Collection gate. Removed; the conftest keeps only its SEL-muting fixture.
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:
- 17 planted-symlink test sites now carry
@unittest.skipUnless(SYMLINKS_OK, ...)with the suite's established reason string. -
test_outputs_are_private_and_leave_no_temp_behindpins its0600assertion behindplatform_compat.IS_POSIXand keeps presence/cleanup assertions unconditional. -
test_followup.pyimports 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
- [x] Single commit with a Conventional Commits title (
test: ...) - [x] Existing tests pass and new tests added for new functionality
- [x] Self-review completed; code follows project style guidelines
- [x] Documentation updated (if applicable) — N/A: test-gating only, no documented behaviour changes
- [x] No secrets, credentials, or internal references in the diff
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.
Authorship Preserved: The Hermes Salvage Story
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 under StrictMode (#93017, salvage #93020)
#93398
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.
Short sessions no longer permanently disable auto-compaction (#93022, salvage #93093)
#93394
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. - Tests: new
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.
RepoMedic: An Entire Hackathon Project in One Day
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.
aniruddhaadak80
/
repomedic
Autonomous OSS repo triage agent on the TrueForge harness — The Agent Harness Hackathon 2026
RepoMedic 🩺
An autonomous open-source repository triage agent, built on TrueForge — the open-source agent harness — for The 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
└──────────────────┘
What it does
| 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.
The Bug Report Factory: 177 Issues of Forensics
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.
security(core): project .env can inject execution-affecting GIT_* variables (GIT_EXEC_PATH, GIT_SSH_COMMAND, GIT_PROXY_COMMAND) into internal git operations; sanitization only strips GIT_CONFIG_*
#29003
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:
- checkpointing initialization —
GitService.initialize()→spawnAsync('git', ['--version'], { env: getSafeGitEnv() })and subsequent shadow-repo commits (git resolves subcommand binaries fromGIT_EXEC_PATH;core.hooksPathis already neutralized, but these env vectors are not) - extension install/update —
cloneFromGit()usessimple-gitwithgetSafeGitEnv(), wheregit.fetch/clonewill invokeGIT_SSH_COMMAND/GIT_PROXY_COMMANDfor non-https remotes - memory/git integration paths using
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.:
- In
getSafeGitEnv()(and the parallel logic ingitService.getShadowRepoEnv()/shellExecutionService.prepareExecution): deleteGIT_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 onlyGIT_CONFIG_*. - Alternatively/additionally, extend
DEFAULT_EXCLUDED_ENV_VARSso project.envfiles 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.envvalues are loaded intoprocess.envunless inDEFAULT_EXCLUDED_ENV_VARS -
packages/cli/src/config/settings.ts:82-87—DEFAULT_EXCLUDED_ENV_VARScontains only 4 entries; noGIT_* -
packages/core/src/utils/gitUtils.ts:9-45—getSafeGitEnv()strips onlyGIT_CONFIG_*/GIT_CONFIG_PARAMETERS -
packages/core/src/services/gitService.ts:102-124— shadow-repo env built from sanitizedprocess.env; execution-affectingGIT_*survive -
packages/cli/src/config/extensions/github.ts:37— extension clones run withgetSafeGitEnv() - Related but distinct: #28684 (env-var load-order race affecting settings resolution) — different defect.
- Duplicate check: searched issues/PRs for "GIT_EXEC_PATH", "GIT_SSH_COMMAND", "safe git env" — no existing report or fix found.
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.
bug: Legacy ingestion overwrites explicit usage.total: 0 via || truthiness bug
#16503
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:
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.
-
Data corruption: Stored
provided_usage_details.totalandusage_details.totalwill be wrong for any SDK that sendstotal: 0 - Dashboard inaccuracy: "Total Usage" metrics, cost calculations, and export data will be inflated
- Cascading: Cost details derived from usage details will also be incorrect since they depend on the stored total
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:
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.
- Whether this is the only place in the ingestion pipeline where
||is used on numeric usage fields -- check ifnewInputCountornewOutputCounthave the same truthiness issue elsewhere in the merge step - Whether the
newInputCount && newOutputCountfallback (line 1929) should also be fixed --0 && ...evaluates to0which is falsy, so it falls through to??. This is technically correct for the fallback path but may warrant explicit!= nullchecks for clarity - Whether any SDKs currently send
total: 0-- if none do, this is a latent bug waiting to happen rather than an actively exploited one
In 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.
The Regex That Almost Ate Mentions: A Langfuse Deep Dive
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.
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.
fix(comments): parse mentions whose display name contains brackets
#16452
@-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})\)
- User-ID charset/length bounds are unchanged; invalid user IDs still never match.
- ReDoS safety is preserved: a single bounded lazy quantifier anchored on a literal suffix has no catastrophic-backtracking path. The existing timing-based tests (1000-char names, repeated brackets, pathological inputs) all pass.
- Worker preview building is extracted into an exported pure
buildCommentPreview()(same file, no behavior change beyond the regex) so it can be unit-tested directly.
- Extended
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 likeJane Doe[ Platform Team ].-
pnpm --filter web run test-client src/features/comments/lib/mentionParser.clienttest.ts→ Tests 57 passed (57)
-
- Added
worker/src/__tests__/comment-mention-preview.test.tscovering regular names, bracketed names, truncation and plain text.-
pnpm --filter worker run test src/__tests__/comment-mention-preview.test.ts→ Tests 4 passed (4)
-
- Targeted ESLint clean on all touched files (web exit 0, worker exit 0);
pnpm --filter web run typecheck→ exit 0; prettier applied to every changed file.
- Mention extraction happens at comment creation, so comments saved before this fix don't retroactively notify anyone; new comments work immediately. Historical tokens remain in stored content either way.
- Rendering of mentions goes through the CommonMark link parser in
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. - One thing worth a second look: with the widened pattern, input like
@[[[[[[[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.
- Uses a bounded lazy display-name capture anchored to the mention user-ID suffix.
- Extracts
buildCommentPreviewinto an exported helper and tests bracketed names and truncation. - Updates parser expectations for nested and repeated brackets.
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
Prompt To Fix All With AI
### 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..." | Re-trigger Greptile
Greptile also left 1 inline comment on this PR.
Context used:
- Knowledge Base — Notifications, Automations, and Outbound Integrations
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.
The Invisible Work: Hygiene, Conflicts, and Graceful Exits
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.
Things Done On My Behalf: Agents Auditing Their Human
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.
What August Actually Taught Me
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.
September Plans, Stated Publicly So I Cannot Weasel Out
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.
Top comments (0)