Does blocking a secret write actually contain the leak?

No, and the README admits it: a secret pasted into chat is already in session context and billed, so blocking the file write hides nothing while interrupting work — real control belongs at the publish boundary.

Why prune only shell output instead of everything?

Search and file results are the data the agent needs and are already truncated at the source by the context tool, so a second pruning layer would cost signal without saving cache.

Will this break my prompt cache like LLM summarizers do?

That is the design goal it was built around: pruning happens in-flight before the message enters history, keeping the prefix byte-stable instead of rewriting past messages.

Why is it marked not in use if the tests pass?

Because the author found terminal compression better handled at the source and the diff guard theatrical; the code and tests stay maintained purely as reference.

What conditions trigger terminal pruning?

Only successful shell tool output. The command must report no error, the output must exceed the length threshold of 4000 characters, and it must run longer than twice the preview line count. Then Jev answers a has-actionable-error question, and if that probability is below 0.20 the middle is dropped while the head and tail stay verbatim.

How does it avoid blocking legitimate .env example edits?

Its deterministic secret layer only flags literal credentials, and it deliberately skips assignment values that are references such as environment lookups or config fields, plus documentation placeholders like example keys. Without that carve-out every legitimate .env.example edit would be blocked. The reference list is a toggle.

How much of a huge build log gets sent to the model?

At most 12,000 characters: 8,000 from the head and 4,000 from the tail. The README says this stops a half-megabyte build log from being billed in full, and also stops it from being silently truncated at the API's 32,000-token limit in the middle of a decision.

CommunityJev Tools & CLIs

Jev Guard — yelkhanyergali-sys

PI agent extension pairing in-flight terminal-output pruning with a surgical diff and secret guard, both driven by typed Jev questions plus a deterministic secret-literal layer.

See highlights

Open github.com

Stars: 1
Language: JavaScript
License: MIT
Published by: Community
Author: yelkhanyergali-sys
Last verified: Oct 2026

yelkhanyergali-sys/jev-guard

User repository on GitHub

View on GitHub

PI Mono extension for Jev (TypeSafe AI): in-flight terminal pruning (prompt-cache safe) and surgical diff guard

Forks: 0
Last pushed: Updated Sep 2026

Repo stats from the GitHub API, cached Oct 2026.

This is one of several Jev listings for the same project. The canonical entry is Jev Guard — leepokai.

About this project

Modern AI coding agents (Claude Code, Cursor, PI Mono) suffer from three fundamental problems during heavy development sessions: Terminal Log Bloat: Running cargo test, pytest, or npm run build dumps 500–1,000 lines of raw compiler/test logs into the conversation context. After 15 runs, 20,000+ tokens of pure boilerplate pollute the context window, causing models to forget initial project instructions (Lost in the Middle effect).

Quoted from the project's README. Read the full README.

Tagscommunity github

Works forJev for Classification

Used inJev for Software & DevTools

Languages: JavaScript

Highlights

Prunes only long successful shell outputs, keeping head and tail verbatim when Jev reports no actionable error below threshold.
Blocks file writes matching known secret literals instantly, then asks Jev about secret modification before touching disk.
Treats drive-by refactors as advisory TUI warnings rather than blocks, and fails soft with a strict timeout that never interrupts work.
Kept as reference: currently unlisted from PI settings, with pruning superseded by source-level metering and leak control moved outward.

Watch out

Reference extension, currently unlisted and superseded; secret blocking does not contain chat-context leaks. Copy reviewed against the repository README on 2026-10-04, not from running it.

Questions about this entry

Short answers drawn from the linked project or page.

More Jev resources like this

using-typesafe-and-pinecone

Example collection pairing Pinecone retrieval with Jev judgments, including a reranking demo that narrows full-text candidates by natural-language criteria.