ESAFENET Compatibility Guide — Claude Code + 亿赛通加密

What Is ESAFENET?

亿赛通 (ESAFENET) CDG is an enterprise Data Loss Prevention (DLP) system that uses transparent encryption (透明加密) to automatically encrypt files at the kernel driver level. It is widely used in Chinese enterprises to protect source code, design documents, and proprietary data.

🔐

Transparent Encryption

Files are encrypted/decrypted automatically by a kernel driver. Users see normal files in whitelisted apps.

📋

Process Binding

Only whitelisted executables can read/write encrypted files. Other processes see garbled data.

🛡️

Central Management

CDG Server controls policies, user groups, file extensions, and approval workflows.

How It Works (Technical)

Three components are installed on each endpoint:

Component	Purpose
CDGRegedit.exe	Main process: GUI, encryption policy updates, user auth
EstVPN.exe	Watchdog: monitors and restarts main process if killed
Filelock.sys	Kernel driver: intercepts file I/O for real-time encrypt/decrypt

ⓘ

Key concept: The Filelock.sys kernel driver intercepts all file read/write operations. Encryption and decryption happen only when both conditions are met: (1) the calling process is in the whitelist, AND (2) the file extension matches that process's approved list. If a process is NOT whitelisted, it sees raw encrypted binary data.

Encryption Method

AES symmetric encryption for file content (random per-file key)
RSA asymmetric encryption wraps the AES key
Encrypted files have header signature: 62 14 23 65
All encryption/decryption occurs in kernel memory — no plaintext temp files on disk

The Problem with Claude Code

ESAFENET was designed for traditional desktop applications (Office, Visual Studio, AutoCAD). It does NOT natively support modern CLI development tools. Here's what breaks:

Claude Code Can't Read Encrypted Files

Claude Code runs as node.exe. If node.exe is not in the process whitelist, it receives garbled binary data instead of source code.

Files Written Lose Encryption

Files created by a non-whitelisted process are saved as unencrypted plaintext, violating security policy.

Git Operations Fail

git.exe is typically not whitelisted, so commits, diffs, and merges produce corrupted results on encrypted files.

Sub-Process Chain Breaks

Claude Code spawns git, shell, compilers, and linters as sub-processes. Each one needs whitelisting or it fails on encrypted files.

✓

Recommendations for IT Admins

Recommended

Option A: Add Processes to Whitelist

Log into the CDG Server management console and add the following processes to the transparent encryption policy's controlled process list (策略管理 → 透明加密策略 → 受控进程):

Process	Why Needed	File Extensions
node.exe	Claude Code runtime, npm, build tools	.js .ts .json .md .html .css .yaml .yml .jsx .tsx .vue .py .java .cpp .h .c
git.exe	Version control (diff, commit, merge)	(same as above)
bash.exe / sh.exe	Shell operations spawned by Claude Code	(same as above)
cmd.exe	Windows command prompt	(same as above)
powershell.exe	PowerShell scripting	(same as above)
python.exe / python3.exe	Python scripts and tooling	.py .json .yaml .yml .txt .cfg .ini

Option B: Directory Exclusions

Request that the following paths are excluded from encryption entirely (落地加解密策略 → 路径排除):

# Directories to exclude from encryption
node_modules\          # npm dependencies (thousands of files)
.git\                  # Git internal data
.claude\               # Claude Code config and cache
%APPDATA%\claude\      # Claude Code app data
%TEMP%\                # Temporary files

Option C: Developer Group Policy

Create a separate organizational unit in CDG Server for developer workstations with a tailored encryption policy that:

Includes all development executables in the process whitelist
Covers all source code file extensions
Excludes development directories from forced encryption
Allows clipboard operations for code (removes character limits)

This provides the most comprehensive solution without weakening security for non-developer departments.

Option D: Switch to Intelligent Encryption Mode

If possible, switch developer machines from forced transparent encryption to intelligent encryption mode (智能加密). In this mode, only files detected as containing sensitive content are encrypted, leaving most source code freely accessible to all tools.

Verification Steps

After IT applies the policy changes, developers should verify:

1

Claude Code can read project files

Open Claude Code in a project directory and ask it to summarize a source file. It should return readable code, not garbled binary.
2

Claude Code can write files

Ask Claude Code to create or modify a file. Verify the saved file can still be opened by other whitelisted applications and remains encrypted on disk.
3

Git operations work correctly

Run git diff and git log -p — output should show readable diffs, not encrypted binary.
4

Encryption is maintained

Check a file's encryption status with a hex editor — encrypted files start with 62 14 23 65. Verify files aren't accidentally saved as plaintext.

★

Quick Reference for IT

Item	Details
CDG Admin Path	/CDGServer3/ → Strategy Management
Process Whitelist Location	Transparent Encryption → Controlled Processes
Required Processes	node.exe, git.exe, bash.exe, cmd.exe, powershell.exe
Key Extensions	.js .ts .json .md .html .css .yaml .py .java .cpp .h .c .vue .jsx .tsx
Exclude Dirs	node_modules\, .git\, .claude\, %TEMP%\
Encrypted File Signature	62 14 23 65 (first 4 bytes)
Admin Roles Required	System Administrator or Security Administrator

⚠

Known Issues & Limitations

Clipboard paste limited to <50 characters ▶

Some ESAFENET configurations restrict clipboard operations for controlled processes. Ask IT to increase or remove the clipboard character limit for developer tools in the CDG policy settings.

Performance degradation on large projects ▶

The kernel-level I/O interception adds overhead to every file read/write. For large projects, request that node_modules/ and .git/ directories are excluded from encryption to significantly reduce overhead.

WSL (Windows Subsystem for Linux) compatibility ▶

ESAFENET's Windows kernel driver does not intercept I/O from WSL Linux processes. Files accessed via WSL may bypass encryption entirely. Check with IT security before using WSL with encrypted projects.

New file extensions not covered ▶

If you work with uncommon file types (.svelte, .astro, .rs, .go, etc.), request IT to add them to the extension list for your whitelisted processes.