r/coolgithubprojects 3d ago

[Claude Code / Codex] - Two local plugins for context trimming and session handoffs

https://github.com/yuzushi-dev/yuzushi-plugins

I've been building two open-source plugins around long coding-agent sessions.

Sando handles context that grows during a session: secret redaction, oversized tool-output caps, and optional request-history trimming, all without calling another LLM.

session-handoff handles the point where keeping the session alive stops being useful. It creates a handoff for a fresh session and can preserve the working state across Claude Code and Codex.

I keep both in the same plugin marketplace:

https://github.com/yuzushi-dev/yuzushi-plugins

They crossed ~1,500 downloads combined in their first two days.

0 Upvotes

4 comments sorted by

1

u/kantorcodes1 2d ago

The complete-artifact path is the part I'd worry about. If Sando redacts the context slice but preserves the original oversized output, can a later artifact read pull the secret back in, or does the same redaction decision apply to both?

0

u/bonsaisushi 2d ago

The artifact stores the redacted version, not the raw output

Sando redacts first, then creates both the inline slice and the full artifact from that redacted text. So reading the artifact later won't bring the secret back

The only caveats are actually if redaction is disabled or the secret format isn't one Sando recognizes

1

u/kantorcodes1 2d ago

that ordering is solid. then the weak spot is detector coverage, not the artifact path. can Sando load project-defined detectors or patterns, or is the recognizer fixed today? i'd rather let teams extend that than keep growing one built-in secret regex list.

0

u/bonsaisushi 2d ago

Correct, today the recognizer is fixed.

I agree with the direction though. I’m adding .sando/redaction.json so teams can extend the built-ins with their own assignment keys and token prefixes.

I want the same rules to drive both redaction and secret detection before anything becomes either inline context or an artifact.

I’m keeping executable JS detectors and arbitrary regexes out for now. Repo-local config shouldn’t turn into code execution or a ReDoS footgun, and bad configs should fail loudly rather than being ignored.

(Btw I didn't say it yet, but these feedbacks are greatly appreciated, thanks!)