[FEATURE] Better tooling for binary file operations (JAR patching, large file handling)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When Claude Code works with compiled Java .jar files, the only available
tool is javap -c (raw bytecode disassembly). There is no access to proper
Java decompilers like cfr or fernflower.

Real-world impact from a Minecraft modpack patching session:

• Had to write a custom ASM patcher (Patcher.java) just to modify

2 methods in jar, because without readable source it took
multiple blind iterations to find the right bytecode offsets

• Patching jar required 3 separate fix attempts because the

actual method logic was only guessable from raw opcodes

• Every patch had to be verified by the end user launching a full Minecraft

instance — no way to catch errors earlier

With cfr or fernflower, Claude could read actual Java source, understand
the logic correctly on the first try, and produce correct patches immediately.

Proposed Solution

When Claude works with .jar files, it should be able to use proper Java
decompilers (cfr, fernflower) instead of only javap -c. This would allow
reading actual source-level code rather than raw bytecode.

For large binary files in git, Claude should detect when a file exceeds
reasonable size limits before attempting to commit/push, warn the user,
and suggest alternatives (Git LFS or skipping the file).

Ideally: a sandboxed java -jar execution to smoke-test patched JARs
without requiring the user to manually launch their application.

Alternative Solutions

Currently working around the javap limitation by writing custom ASM patcher
scripts and running multiple decompile iterations to guess bytecode structure.

For large files: manually tracking which files to commit and which to skip,
which led to a failed 1.9 GB push that corrupted the git workflow mid-session.

No real alternative exists for runtime verification — the user has to test
manually every time.

Priority

Critical - Blocking my work

Feature Category

File operations

Use Case Example

Scenario: Patching a compiled Minecraft mod (.jar) to fix gameplay behavior.

1. The user suggests claude to change/fix something in .jar
2. Claude runs javap -c for target classes — gets raw bytecode,

no variable names, no readable logic

1. Claude must create a subagent to guess the structure, match

several methods, perform 3-4 decompilation attempts, just to understand what is doing.

1. With cfr/fernflower: Claude reads the Java source code in one step,

immediately understands the logic, writes the correct ASM patch on the first try

1. Time saved: ~40 minutes for each corrected method.

Additional Context

cfr is open source (MIT license): https://github.com/leibnitz27/cfr
fernflower is bundled with IntelliJ IDEA (Apache 2.0).
additionally, I created a folder "helper claude" which has : ASMInjector-main, guava-33.5.0-jre, DecompilerMC_win, HTTPClient, jar-editor-master, jasm-1.1.1, java-portable-master, java-scriptengine-2.0.0, javassist, Krakatau-2, maven-maven-3.9.14, MDK-Forge-1.20.1-ModDevGradle-main, procyon-decompiler-0.6.0, recaf-launcher-cli-0.8.8 (upgrade ASM), threadfactory-1.5.2

most of them turned out to be garbage, Claude and I wrote our very good one. СlaudePatcher.jar
bytecode command is a complete replacement for javap -c + javap -verbose:

$CP bytecode name.jar [AAA] initialize
$CP bytecode name.jar MinecraftClientMixin name$get...  
$CP bytecode name.jar ClassName --synthetic # all lambda$ methods

Color output: CYAN = mod calls, YELLOW = strings, BOLD = INVOKEDYNAMIC
INVOKEDYNAMIC expands bootstrap args with names of lambda implementations
No more jar xf + javap + grep needed

Both can be invoked as: java -jar cfr.jar TargetClass.class
No installation needed beyond having the jar available.

This would benefit any Claude Code user working with:

• Android APK reverse engineering
• Java library patching
• Minecraft mod development
• Any compiled JVM bytecode analysis

Note: I am using Claude Code web version (claude.ai/code), not the desktop
CLI. The web version has even more restricted tool access than the CLI —
no ability to install additional utilities like cfr/fernflower even as a
workaround. Desktop PC version is blocked for some users with no alternative
offered, making the web version the only option.