DEV Community: ArcticFoxz

Three checks that were green for the wrong reason

ArcticFoxz — Wed, 16 Sep 2026 04:43:56 +0000

I shipped a release yesterday. Four CI rounds, most of a day, and the part worth writing down isn't the release — it's that three checks in my own test suite had been passing for reasons that had nothing to do with what they claimed to test, and I only found out because a platform I don't own ran them.

They're three separate mechanisms. That's what makes them worth reading about: I didn't make one mistake three times, I made three different mistakes that all produce the same symptom, which is a green check that means nothing.

One: the trigger that never fired

The feature is small. A rule file in the workspace can declare Applies to: lib/redact.py, and when the files it names are the ones being edited, that rule gets more room in the context block than one that declares nothing. The check compares the two and asserts the scoped one wins.

It passed on macOS. It failed on Windows. I spent a while assuming that meant something about Windows.

It didn't. The check builds a temp repository and commits into it — five commits. The ranking it depends on returns nothing below fifty commits, so the trigger under test had never fired, on any platform, since the check was written. What it was actually comparing was the raw length of two strings, and the scoped rule's body is longer than the unscoped one for a reason you can probably guess: it carries the Applies to: line. Forty-one characters. That was the entire margin it had been passing by.

Windows didn't find a Windows bug. Windows got unlucky with string lengths in the other direction and exposed a check that had never worked.

Fixed by making the fixture commit past the constant it depends on, derived from the constant rather than hardcoded:

for i in range(_rollup.MIN_COMMITS_TO_RANK + 2):

With the trigger actually firing: scoped 541 characters, unscoped 306, elsewhere 300. Against 411 / 370 / 371 before. The feature works. Nothing had ever shown that, and it was named in the release notes.

Two: the check that was never the platform under test

This one is almost funny. A detector warns when a repository contains a file named like a program the tool is about to run, because Windows searches the current directory before PATH. The check forces sys.platform = "win32", exercises the detector, restores the platform, and then asserts the detector stays quiet — "it stays silent on a platform that does not search the current directory."

On a Mac that's true. On Windows the real platform is the platform under test, the detector correctly fires, and the check fails.

I'd written a check whose final assertion was only correct on machines that are not the thing it tests.

Three: a floor finer than the clock

CI reported this:

FAIL  late failure on 'identifiers' grows no worse than linearly:
      0.0 ms at 4 KiB, 31.2 ms at 16 KiB (x625.0)

Four times the input, 625 times the CPU. That reads like a catastrophic regression in a redaction routine.

The line doing the dividing:

ratio = big / max(small, 0.05)

process_time() on Windows advances on the scheduler tick, roughly every 15.6 ms. The 4 KiB case is faster than that, so it reads 0.0. The floor supplies 0.05. And 31.2 / 0.05 is 624.

The tell was in the log the whole time and I didn't see it for a while: 31.2 is exactly 15.6 x 2. Both numbers were quantised to ticks. Also, the same input passed on Python 3.8 in the same run — a real quadratic blowup doesn't care which interpreter you use.

The fix is autoranging, the way timeit does it: repeat the small case until the total is genuinely measurable, then measure both sizes at that same repeat count and divide the totals.

And then I got it wrong a second time, which is the part I actually want to write down.

The second mistake inside the fix

My first version keyed the target off time.get_clock_info("process_time").resolution.

That's a documented API returning a real number, and on Windows it is 1e-07. One hundred nanoseconds — the unit GetProcessTimes returns its values in. It is not the rate at which those values change, which is the 15.6 ms tick. So the target would have been 0.002 ms, the autorange would have stopped immediately, and the fix would have been a no-op on the only platform it exists for.

It would also have passed every local test, because this Mac's clock really does resolve to a microsecond and the repeat count stays at 1 here no matter what.

Measure the tick instead of asking for it:

t0 = time.process_time()
while True:
    t1 = time.process_time()
    if t1 != t0:
        return (t1 - t0) * 1000.0

Take the larger of that and the reported resolution. On macOS nothing changes. On Windows the target becomes ~312 ms and the autorange does its job.

How I checked it this time

The thing that had bitten me three times in one day was believing a green result from a mechanism that had never engaged. So before trusting the fix I forced the resolution to 15.6 ms in a scratch copy and watched what the autorange did:

'identifiers': resolution 15.600 ms, repeated x64 to reach a 512.493 ms baseline
'digits':      resolution 15.600 ms, repeated x32 to reach a 319.907 ms baseline
'spaces':      resolution 15.600 ms, repeated x8  to reach a 312.779 ms baseline

Ten lines of Python, no VM, no second machine. The mechanism engaged, the baselines became real numbers, and the check still passed. That is evidence. The earlier run where everything was green and repeat was 1 everywhere was not.

What I'd take from it

Three mechanisms, one symptom:

a population that was never gathered (five commits against a threshold of fifty)
an environment that was never entered (the check ran on the platform it wasn't about)
a mechanism that never engaged (repeat stuck at 1 on a fast clock)

None of them announces itself. All three look exactly like a passing test, and a passing test is the thing you least want to go and re-examine.

The habit I'm trying to build from it is narrow enough to actually follow: before believing a check, make it fail on purpose. Not "does it pass" — "have I watched this go red for the reason it exists?" It cost me ten minutes per check. It would have saved most of a day.

And the part I keep turning over: none of these were bugs in the shipped code. Every one was in the apparatus I use to decide whether the shipped code is correct. The tools were fine. The instruments were lying.

A redactor that only spoke English, and the test that would have caught it

ArcticFoxz — Mon, 14 Sep 2026 09:16:29 +0000

Two files are worth more than anything I could write here, so this post is mostly directions.

`tools/verify_release.py`

git clone https://github.com/ArcticFox2029/chamnan && cd chamnan
python3 tools/verify_release.py

It re-runs the whole suite on your machine and prints what happened on yours. 5,081 checks, 5,081 passed, 0 failed here. Your total will land near that rather than on it — some checks need a developer setup a clone does not have, so they say they were skipped instead of running, and how many depends on your OS. The half that should be identical everywhere is the second one.

The reason it exists: the tool refuses to report a result at all when the suite's totals line is missing. A run that dies half way prints no failure lines, so grepping for failures reads zero over a run that stopped early. That distinction cost me a morning once.

`INDEX_CITED_IN_CODE.md`

Attached to the release. Every place in the shipped source where a defect that a research round found got fixed, linked to the commit that fixed it. 21 of them landed in this release; 722 in total. It means a claim in the notes can be followed to a diff instead of taken on trust.

If you want the reason any of that matters, it is the thing this release leads with.

A credential redactor had been catching password and walking straight past รหัสผ่าน, 密码, 비밀번호, كلمة المرور and six more spellings of the same word. Three of thirty cases caught. It is thirty of thirty now.

The vocabulary was already in the file. Somebody had added it for reading CSV header rows and never wired it to the patterns that read an assignment — same words, one path covered, the identical path beside it missed.

What I got wrong in the first fix was grouping by language. German, Italian, Dutch and Indonesian are not English and are plain ASCII; the thing that actually decides the rule is the writing system. Thai, Chinese, Japanese and Korean put no spaces between words, so a keyword joined to the next word is ordinary writing there and has to be caught. Latin, Cyrillic, Arabic and Devanagari keep boundaries, so passwordless has to be left alone. Two different rules, and the axis that separates them is not the one on the language dropdown.

Then a second one, found by asking the same question a different way: a variable called secret, assigned the word secret, printed its value. So did credential, apikey, passphrase, auth, cred, keypass, storepass, passwd and secretkey. Only password was caught — an earlier exemption answered "that's a label" for every one of them and ran before the rule that would have caught it. The fix that closed password had landed on one member of a set of twelve.

The test that caught the first of those asserted one example. Its replacement derives the whole credential vocabulary from the module and asserts every word in it, so a thirteenth joins on the day it is added. That is the part I would steal if I were reading someone else's release notes: assert the population, not the member.

One number in here you cannot reproduce from a clone, and I would rather say so than let you find out: the recall figure is measured against a synthetic corpus built to be hard to index, and it is not in the repository. The 5,081 is reproducible. The recall number is not.

There is also a new command, chamnan-schedule — name a time and your work resumes then, carrying a pointer to where the work is written down rather than a command line, because "finish what you were doing" is not something a command line can say. It is a schedule and never an auto-renew: nothing detects a limit, nothing decides on its own to resume.

What are you using to catch this class of thing? I am especially interested in anyone who has found a way to test a language they do not read.

A blended recall number hid an entire class of leak

ArcticFoxz — Fri, 11 Sep 2026 06:00:13 +0000

chamnan is a Claude Code plugin that keeps engineering context in the repository, so an agent
stops rediscovering the same work every session. Part of that is a redactor: it scrubs what the
tool sends out, before it reaches a model backend.

It scored 98.3% recall on a labelled corpus. That number was true and it was hiding something.

The number was measured over a corpus missing the case it was about

A reader — Peter — made an argument on somebody else's
article: a pipeline can hit strong recall on straightforward payloads while systematically
missing anything harder, and a blended recall number hides that completely.

So I split the figure by the retrieval problem each case poses. A credential can be named by an
assignment (API_KEY=...), positioned under a column header, described in surrounding prose, or
standing bare with nothing but its own characters to go on.

The column-header class had zero cases in it.

That is the class that leaked. A password under a CSV header — nombre,correo,contraseña —
escaped in every language the redactor claimed to handle, English included. The fix shipped. The
measurement that should have caught it had never sampled it once.

An empty class does not show up in a breakdown as a zero. It does not show up at all, which is
how it survived being looked at.

The fix moved the headline the wrong way

The corpus now derives its column cases from the redactor's own list of claimed languages, so a
language it claims is a language it is measured on. Sixteen languages, thirty-six cases.

All thirty-six pass — so the blended figure went up, 98.3% to 99.0%.

That is the same defect from the other side. A headline improved by testing more of what already
works flatters exactly as much as one that hides a weak class. So both numbers are published now:
99.0% overall, 93.8% in the weakest class, and a check fails if either goes missing from the
README or SECURITY.md.

Three more places a number could be confidently wrong

Peter's other arguments turned into three more fixes:

A rate without its denominator. Every reported rate now carries the count it was computed over — a rate over a shrinking, unwatched denominator produces a confident green with nothing behind it.
A third state for "cannot decide". A file the parser refuses is not a file nobody documented, and only one of those is fixable by writing a docstring. The coverage line says which is which — and still counts them, because removing them raises the percentage, which would mean a repository scoring better because the tool can read less of it.
A list of accepted findings that could grow unnoticed. When a self-scan finds something new, the cheapest way to make the check pass is to add it to the accepted list, which silences a real finding exactly as well as fixing one. That list has a ceiling now, and raising it has to appear in a diff.

Checking it

check 4869 / 4869, and 1,466 of 1,466 index claims true, on Linux, macOS and Windows across two
Python versions.

git clone https://github.com/ArcticFox2029/chamnan
cd chamnan && python3 tools/verify_release.py

It runs the suite and the index-claim check on your machine and prints what happened. It refuses
to report a result when the totals line is missing, because a run that dies mid-way prints no
failure lines at all.

One honest limit: the recall corpus is synthetic, built to be hard to index, and is not part
of the repository — so you cannot reproduce those particular numbers from a clone. The suite and
the index claims you can.

MIT. Python standard library only. Nothing leaves the machine.

The bug that only existed on the platform nobody was looking at

ArcticFoxz — Wed, 09 Sep 2026 02:14:44 +0000

I ship a Python tool with a regression suite of several thousand checks and CI on ubuntu, macOS and
Windows at Python 3.8 and 3.13. Yesterday all five jobs were green. Today those same jobs turned up
four defects that had already shipped.

None of them errored. Each was a rule that was true on the machine it was written on.

1. A guard that compared a resolved path to an unresolved one

The tool has a command that reads one file into the model's context. It refuses a symlink that a
repository chose whose target sits outside that repository — a repo shipping docs/notes.md -> ~/.ssh/id_rsa should not get that file read aloud.

The guard looked like this:

root = find_root()                      # returns a RESOLVED path
named_inside = any(r in Path(os.path.abspath(target)).parents
                   for r in (root, root.resolve()))
if Path(target).exists() and named_inside and not inside(Path(target), root):
    refuse()

os.path.abspath does not resolve anything. It joins the name onto os.getcwd(). On POSIX that is
harmless, because getcwd() returns a canonical path with no symlinks in it — so both sides always
agreed and the guard always fired.

Windows does not do that. GetCurrentDirectory hands back whatever string the process was started
with, short 8.3 components and all. A repository reached through C:\Users\RUNNER~1\... produced
named_inside = False, and the file outside the repository was read exactly as it had been before
the guard was written. The guard was not weaker on Windows. It was absent.

The fix resolves the containing directory — which has no final symlink in it, so it normalises the
name without following the link being judged:

named_dir = Path(os.path.abspath(target)).parent.resolve()
root_dir  = Path(root).resolve()
named_inside = named_dir == root_dir or root_dir in named_dir.parents

I could not reproduce this on macOS. getcwd() canonicalises even if you chdir through a symlink,
so the asymmetry cannot be staged on the platform I develop on. That matters for the rest of this
post.

2. A carriage return no one would ever see

The tool installs an optional pre-commit hook. It rebuilds an index, stages it, then reads back
which files it wrote and refreshes each one:

mytool --written-files | while read -r name; do
  written=$(mytool --write "$name" | sed -n 's/^wrote -> //p')
  [ -n "$written" ] && git add -- "$written"
done

Under git's bundled shell on Windows, Python ends every line with CR LF. read -r keeps the CR. So
name is generic\r, and --write "generic\r" is not a valid choice — argparse refuses it. The
loop wrote nothing and staged nothing, on every commit, for as long as the loop had existed.

The line above it worked the whole time, because it parses no output. So the index looked healthy
while every generated file stood still, and the README went on describing this hook as the thing
that keeps them current.

tr -d '\r' on both readings fixes it. Then I fixed it wrong: the hook body is a Python string, not
a raw one, so writing \r in the source put a real carriage return into the installed hook — the
exact opposite of the intent, and it broke the hook on all five jobs instead of the one it was
written for. The check I had added alongside read the source text, saw two characters, and
reported the escape as present.

The check that caught it was an older one that reads the installed file.

That is the whole lesson of this section: assert on the artifact, not on the source that produces it.

3. The instruction that did nothing when pasted

On a first run that cannot find its commands on your PATH, the tool prints the line to add:

export PATH="/path/to/bin:$PATH"

To every operating system. On Windows that is wrong three times over — export is not a command,
$PATH is not the variable, : is not the separator. The single instruction a new Windows user is
given did nothing when they pasted it.

And the test asserted "export PATH=" in output — on Windows too. The platform where the advice was
useless was the platform confirming it was correct.

4. Not a platform at all: an interpreter

A symlink loop (a -> b -> a) makes Path.resolve() raise. The walk caught that and dropped the
entry in silence — the one exit from that function that recorded nothing, while every other exit
reports what it refused.

Python 3.13 rewrote Path.resolve() onto os.path.realpath(strict=False), which returns a path for
a loop instead of raising. So the same tree was reported honestly on 3.13 and silently truncated on
3.8 through 3.12, under a coverage bar reading 100% over a smaller set than the one it walked.

The check covering it passed on the version I happen to run.

What actually found these

Not cleverness. Two things:

A failing check that prints what it saw. My suite's helper took a name and a boolean. A failing
check said what was expected and nothing about what happened, which is fine when you can re-run it —
and useless when it only fails on a platform you do not have. One round of CI was spent on four FAIL
lines and a guess, and the guess was wrong. So:

def check(name, condition, saw=None):
    if condition:
        PASSED += 1
    else:
        print(f"  FAIL  {name}")
        if saw is not None:                      # only on failure
            for line in str(saw).splitlines()[:6]:
                print(f"        SAW  {line[:200]}")

The very next run printed a commit stat showing the index refreshed and the generated file
untouched. That is section 2, diagnosed in one round instead of three.

Assert the population, not the member. Every one of these is the same shape: a rule applied to
some members of a set and forgotten in the identical ones beside it. So the checks are derived from
source rather than pinned to the line that was wrong. When I fixed the CR in the hook, the check I
wrote was "every place this script reads output produced by a Python program strips CR", derived
from the hook text — not "line 46 has tr -d".

That habit paid immediately somewhere else. GitHub's push protection refused the release over three
test credentials written as literals. The file already had a helper that assembles fake credentials
at runtime, forty lines above, whose docstring says push protection blocked this repository's first
push over exactly these lines. It had been used for some fixtures and not the ones beside them. I
wrote the check over the whole file instead of the three, and it immediately found four more —
GitLab, GitHub, Stripe, Anthropic — already in the published tree, which would refuse a fork's first
push the same way.

The one that was not about platforms at all

After the release went out I swept the published tree for something else: my own machine.

Two defect comments used a real encoded path as their example — my account name and the directory
layout of unrelated work, sitting in a public repository since a release three versions back. Not a
secret in any scanner's sense, which is exactly why nothing stopped them. A published
CODE_OF_CONDUCT.md printed a contact address that a private security advisory link would have
covered without one.

Both are now checks over every tracked file, not fixes to the four lines that were wrong: no shipped
file may quote a real home directory rather than an invented one, and no published document may
print an address outside the reserved example domains a test is supposed to use. The first one
matched its own sanity assertion on the first run, because that line contains a real-looking path;
it builds the needle at runtime now.

Four gates, and the thing that walked past all of them

By the end of the day I had four checks standing between the repository and a leak: no real home
directory in a tracked file, no address in a published document, no credential fixture written as a
literal, and the project's own redactor — seventy-one credential shapes — swept over every tracked
file against a committed baseline. The tree came back clean on all four.

Then I wrote a fifth check that reads a list of terms instead of guessing a shape. Not a pattern: a
plain list of the specific words that must never appear, kept in a file outside every repository,
because a list of things you must not publish is the most concentrated form of the thing you must
not publish.

It failed on the first run. A test fixture in the shipped suite carried a real operational
constraint from my own production work — an imperative sentence naming a real cluster, pasted in
while debugging months earlier. Not a path. Not an address. Not a credential. Nothing was looking
for it, because every check I had written looked for a shape, and this was just a sentence.

That is the argument for the list. Shape-matching catches the classes you have already been burned
by. The next leak is, by definition, the one whose shape you did not think to describe — and the
only thing that catches it is knowing, concretely, what your own secrets are called.

The uncomfortable part

CI ran green on Windows for months while two of these were live. The jobs were not lying; they were
running checks that asked the wrong question, written by someone who could only picture one platform
while writing them. A cross-platform matrix tells you the suite passes everywhere. It does not tell
you the suite is asking the same thing everywhere.

The tool is chamnan — MIT, Python 3.8+, standard library
only, runs entirely locally. python3 tools/verify_release.py from a clean clone re-runs everything
this post quotes and prints what happened on your machine.

Measure a context plugin on your own repository before you install it

ArcticFoxz — Mon, 07 Sep 2026 20:01:51 +0000

Every plugin in this category tells you it reduces context cost. None of them let you check on your
own code first, so I built the page that does, and it is the first thing chamnan 1.23.1 ships.

arcticfox2029.github.io/chamnan-measure

Paste a public GitHub repository URL. The page downloads the source into your browser tab, runs
chamnan's actual modules over it through Pyodide — mapper, rollup, the redactor, not a
re-implementation of any of them — and reports what would be injected into an agent's context each
session, what the redactor would alter, and a fifty-turn simulation over that repository's own
files.

No server. No upload. No API key. The source is deleted the moment the numbers exist. It works in
five languages.

What the numbers say, and what they do not

Thirteen repositories are measured on the page already:

repository	language	source	injected	ratio
chalk/chalk	JavaScript	56 KB	2,449 B	24:1
psf/requests	Python	392 KB	6,345 B	63:1
rails/rails	Ruby	1,550 KB	6,537 B	243:1
django/django	Python	2,209 KB	6,245 B	362:1
torvalds/linux	C	3,028 KB	6,603 B	470:1
vuejs/core	TypeScript	3,782 KB	6,250 B	620:1

The interesting column is not the ratio. It is that the source grows nearly seventy-fold down that
table and the injected block stays between 6.2 and 6.7 KB. That is a bound, not compression —
the index is rolled up to a token budget, so a bigger repository buys you a coarser map rather than
a bigger bill.

The ratio is a consequence of the bound, which is why quoting it alone would be the flattering
version. A 25.4x figure on the published corpus is the honest headline for compression; the same
measurement on a corpus padded with binary attachments produces 223x, and this project's own README
records the time that number was corrected for choosing the flattering corpus.

The release itself is one defect, found in fourteen places

Not fourteen unrelated bugs. One shape, repeated: a rule applied to some members of a set and
forgotten in the identical ones beside it. They were written months apart, found by separate
research rounds, and naming them together is the only way the pattern is visible.

A few of them:

Path.glob raises NotImplementedError — not ValueError, not OSError — for a pattern beginning with /. One committed rule file reading **Check:** absent `X` in every `/etc/*` ended the injected context block where it stood: the last session's handoff, open threads, the tools index, all silently absent, every session, under a message that never named the rule. A rule file arrives with a clone, so this needed no local access at all.
A committed tools index with "runs": "12" instead of 12 crashed the same hook through sort(key=lambda t: -(t.get("runs") or 0)). The name in that file was validated, because a name becomes a path. A sort key is exactly where an untrusted field turns into arithmetic.
All three context-injecting hooks failed to strip zero-width characters, each differently. Two bypassed the sanitiser with a raw write; the third called it faithfully on the finished JSON, by which point json.dumps has escaped every smuggled code point to \uXXXX text no character filter matches and the model decodes straight back. Reproduced end to end: 44 Unicode Tag characters in, an instruction back out.
Eleven places wrapped a repository-derived name in backticks. POSIX permits a backtick in a filename, and one closes the code span — after which the repository's data renders as the tool's own voice. A report named two of them; the sweep found nine more.

What I would do differently, since that is the more useful half

The Windows column of the CI matrix caught five things a Mac could not, and I spent an evening
learning them one push at a time. Four of the five were findable locally and I did not look: a
#!/bin/sh test fixture Windows cannot execute, a path compared without normalising separators, a
/nonexistent-… path that Windows resolves against the current drive and happily creates, and a
subprocess spawn added to the session-start path that took CI from 4m16s to 9m25s.

The fifth was a real concurrency defect, and it is the one worth writing down. The file lock gave a
waiter a fixed two seconds and then let the caller write unguarded. Four hundred turns through one
lock drain inside two seconds only if a turn is cheap; on Windows it is not, and the counter came
back 41 of 400 — lost, silently, on a running total nothing recomputes.

I reproduced it on macOS in thirty seconds by shrinking the ceiling to 0.05 s instead of finding a
Windows machine. Squeezing a constant is the same experiment as slowing the disk, and it runs
where you are already sitting. That squeeze is a permanent check now, on every platform.

The rest

MIT. Standard library only — no dependency step in CI, and if it ever needs one, that is the change
to reject rather than the workflow to fix. 21 languages parsed, 23 adapters, tested on Ubuntu,
macOS and Windows across Python 3.8 and 3.13.

github.com/ArcticFox2029/chamnan

Built a local pre-processing plugin for Claude Code after research & measuring real metrics (3,500+ tests, v1.22.1) — Looking for feedback & ideas

ArcticFoxz — Mon, 07 Sep 2026 07:11:16 +0000

Hi everyone,

I wanted to share a project I’ve been developing for my own workflow with Claude Code, and hopefully get some feedback and ideas from the community on where to take it next.

How it started

Working on large-scale, complex projects, I needed better control over context, token consumption, and security. Before building my own tool, I tested various plugins in the market. As someone who likes to measure and verify metrics independently, I ran tests on actual context usage and noticed that under large, messy repository conditions, results often varied from what was expected.

Since my projects involve sensitive codebases, I wanted a deterministic local pre-processing layer that sanitizes, budgets, and organizes data before anything is passed to Claude Code—ensuring zero unexpected data leaks and absolute predictability.

The struggle & research

What started as a simple helper script turned into a serious engineering effort. I went through over 1,000 research papers and technical docs to refine context retention, token budgeting, and local redaction.

Building reliability tooling is a constant battle against edge cases: silent context loss, false successes, cross-platform path quirks (like Windows process locks), and state drift.

My rule became: Never believe a bug is fixed until a test proves it.

Today, the plugin (chamnan) is at v1.22.1. It's built in pure Python (standard library only, zero external packages) and backed by 3,500+ automated tests.

What it actually does (It's NOT an AI, it's a pre-processing / reliability layer)

Deterministic Context Budgeting: Pre-indexes and trims repository context before passing it to Claude Code (slashed Quick Index overhead dramatically in real-world tests).
Local Security & Redaction: Runs local choke-point scrubbing so secrets and internal strings never leave your machine.
Agent Continuity / Memory: Keeps track of session decisions, lessons, and project history locally inside .chamnan/ so Claude Code doesn't waste tokens re-discovering architecture across sessions.
Monorepo & Multi-adapter support: Designed to handle nested checkouts, messy directory trees, and OS-specific edge cases cleanly.

Looking for community feedback

I dogfood this daily, but since I built it to share with other developers working on large or privacy-conscious projects, I'd love to hear your thoughts:

What edge cases or repository structures have broken your Claude Code workflows in the past?
What safety verifications or context features would you like to see in a local helper plugin?

If you're interested in the architecture or test setup, you can check out the repository here: https://github.com/ArcticFox2029/chamnan

Appreciate any feedback!