Back to Setup Guide
IT Admin Action Required

ESAFENET EncryptionCompatibility Guide

How to configure ESAFENET CDG transparent encryption to work with Claude Code and modern CLI development tools.

1

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.
2

How It Works (Technical)

Three components are installed on each endpoint:

ComponentPurpose
CDGRegedit.exeMain process: GUI, encryption policy updates, user auth
EstVPN.exeWatchdog: monitors and restarts main process if killed
Filelock.sysKernel 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:

ProcessWhy NeededFile Extensions
node.exeClaude Code runtime, npm, build tools.js .ts .json .md .html .css .yaml .yml .jsx .tsx .vue .py .java .cpp .h .c
git.exeVersion control (diff, commit, merge)(same as above)
bash.exe / sh.exeShell operations spawned by Claude Code(same as above)
cmd.exeWindows command prompt(same as above)
powershell.exePowerShell scripting(same as above)
python.exe / python3.exePython 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.

5

Verification Steps

After IT applies the policy changes, developers should verify:

  1. 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. 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. 3

    Git operations work correctly

    Run git diff and git log -p β€” output should show readable diffs, not encrypted binary.

  4. 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

ItemDetails
CDG Admin Path/CDGServer3/ β†’ Strategy Management
Process Whitelist LocationTransparent Encryption β†’ Controlled Processes
Required Processesnode.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 Dirsnode_modules\, .git\, .claude\, %TEMP%\
Encrypted File Signature62 14 23 65 (first 4 bytes)
Admin Roles RequiredSystem 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.

ESAFENET Compatibility Guide β€” Claude Code