If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/2dust/clashN shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 2y ago

• 8 active contributors
• GPL-3.0 licensed
• ⚠ Stale — last commit 2y ago
• ⚠ Concentrated ownership — top contributor handles 76% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live 2dust/clashN repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/2dust/clashN.

What it runs against: a local clone of 2dust/clashN — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in 2dust/clashN | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 710 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of 2dust/clashN. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/2dust/clashN.git
#   cd clashN
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of 2dust/clashN and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "2dust/clashN(\\.git)?\\b" \\
  && ok "origin remote is 2dust/clashN" \\
  || miss "origin remote is not 2dust/clashN (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "clashN/clashN/App.xaml.cs" \\
  && ok "clashN/clashN/App.xaml.cs" \\
  || miss "missing critical file: clashN/clashN/App.xaml.cs"
test -f "clashN/clashN/Handler/CoreHandler.cs" \\
  && ok "clashN/clashN/Handler/CoreHandler.cs" \\
  || miss "missing critical file: clashN/clashN/Handler/CoreHandler.cs"
test -f "clashN/clashN/Handler/ConfigProc.cs" \\
  && ok "clashN/clashN/Handler/ConfigProc.cs" \\
  || miss "missing critical file: clashN/clashN/Handler/ConfigProc.cs"
test -f "clashN/clashN/ViewModels/MainWindowViewModel.cs" \\
  && ok "clashN/clashN/ViewModels/MainWindowViewModel.cs" \\
  || miss "missing critical file: clashN/clashN/ViewModels/MainWindowViewModel.cs"
test -f "clashN/clashN/Handler/SysProxyHandle.cs" \\
  && ok "clashN/clashN/Handler/SysProxyHandle.cs" \\
  || miss "missing critical file: clashN/clashN/Handler/SysProxyHandle.cs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 710 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~680d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/2dust/clashN"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

ClashN is a Windows GUI client for the Mihomo proxy core (a Clash implementation), enabling users to manage proxy configurations, test connection speeds, and route traffic through configurable proxy profiles. It supports subscription management, rule modes, and system-wide proxy settings, with plans to merge functionality into the larger v2rayN project. Monolithic WPF desktop application: clashN/clashN contains the entire codebase organized by feature (Handler/ for business logic like CoreHandler, ConfigProc; Mode/ for data models; Converters/ for UI binding; Base/ for utilities). Depends heavily on v2rayN repository shared code, requiring both repos to be siblings during build.

Windows users who need a lightweight proxy client for Mihomo/Clash, and developers maintaining proxy infrastructure who want a desktop GUI alternative to command-line configuration. Network enthusiasts and privacy-conscious users managing multiple proxy profiles.

Actively maintained but with planned deprecation: the project shows recent commit activity and functional releases (with .NET 8.0 Desktop Runtime requirement), but the README explicitly states that 'this project's functionality will be merged into v2rayN' (issue #358), indicating this is a transitional project rather than long-term maintained. Production-ready for current users, but migration path planned.

Primary risk is maintainer-driven deprecation: the project is being consolidated into v2rayN, so new feature development is unlikely. Dependency on Mihomo core (external project) and tight coupling with v2rayN codebase (requires cloning both repos to build) creates fragility. Limited visible test coverage in file structure, and single-maintainer (2dust) pattern suggests bus factor risk.

The project is in maintenance mode with focus on stability. The README announcement about merging into v2rayN indicates active development is redirected upstream. No specific PRs or milestones visible in provided data, but commits continue (indicated by 'commit activity' badge). The project is functionally complete but not expanding.

1. Clone both repositories as siblings: git clone https://github.com/2dust/clashN && git clone https://github.com/2dust/v2rayN (both must be in same parent folder per README). 2. Open clashN/clashN/clashN.sln in Visual Studio. 3. Ensure .NET 8.0 Desktop Runtime is installed. 4. Build and run ClashN.exe.

Daily commands: After building in Visual Studio: execute ClashN.exe directly from bin/Release or bin/Debug. Application launches with system tray integration (NotifyIcon1/2/3.ico resources). Requires Mihomo core binary to be available on system PATH or configured location (handled by CoreHandler.cs).

• clashN/clashN/App.xaml.cs — Application entry point and initialization; handles core startup logic and global exception handling.
• clashN/clashN/Handler/CoreHandler.cs — Manages Mihomo core lifecycle (start, stop, restart); critical for proxy engine operation.
• clashN/clashN/Handler/ConfigProc.cs — Processes and validates configuration files; essential for profile and subscription management.
• clashN/clashN/ViewModels/MainWindowViewModel.cs — Primary ViewModel for main UI; orchestrates all major view state and user interactions.
• clashN/clashN/Handler/SysProxyHandle.cs — System proxy configuration integration; critical path for applying proxy settings to Windows.
• clashN/clashN/Global.cs — Global state and configuration container; accessed throughout the application.
• clashN/clashN/Mode/Config.cs — Core data model for application configuration; defines serialization and validation rules.

Add a new proxy selection mode or feature to ProxiesView

1. Create a new ViewModel command in ProxiesViewModel.cs to handle the feature logic (clashN/clashN/ViewModels/ProxiesViewModel.cs)
2. Add UI binding in ProxiesView.xaml (button, dropdown, or toggle) using Material Design controls (clashN/clashN/Views/ProxiesView.xaml)
3. If feature requires Mihomo API calls, extend ClashProxies.cs model or add API route handling (clashN/clashN/Mode/ClashProxies.cs)
4. Add localization strings to ResUI.resx and ResUI.zh-Hans.resx (clashN/clashN/Resx/ResUI.resx)

Add support for a new subscription format or profile field

1. Extend the ProfileItemModel.cs with new fields and serialize/deserialize logic (clashN/clashN/Mode/ProfileItemModel.cs)
2. Update ConfigProc.cs parser to extract and validate the new format from subscription files (clashN/clashN/Handler/ConfigProc.cs)
3. Modify CoreConfigHandler.cs if new fields affect Mihomo config generation (clashN/clashN/Handler/CoreConfigHandler.cs)
4. Add UI controls in PorfileEditWindow.xaml and ProfileEditViewModel.cs for user input (clashN/clashN/Views/PorfileEditWindow.xaml)

Add a new settings tab or configuration option

1. Add property to Config.cs class; ensure JSON serialization compatibility (clashN/clashN/Mode/Config.cs)
2. Create XAML UI controls in SettingsView.xaml using Material Design (clashN/clashN/Views/SettingsView.xaml)
3. Bind controls and implement save/load logic in SettingsViewModel.cs (clashN/clashN/ViewModels/SettingsViewModel.cs)
4. If the setting affects Mihomo config, update CoreConfigHandler.cs to apply it (clashN/clashN/Handler/CoreConfigHandler.cs)
5. Add localized labels to ResUI.resx and ResUI.zh-Hans.resx (clashN/clashN/Resx/ResUI.resx)

Add a new statistics or monitoring metric to the Dashboard

1. If needed, extend ServerStatistics.cs or ClashConnections.cs model with new fields (clashN/clashN/Mode/ServerStatistics.cs)
2. Update StatisticsHandler.cs to fetch or compute the new metric from Mihomo API (clashN/clashN/Handler/StatisticsHandler.cs)
3. Add UI controls and data-binding in DashboardView.xaml (clashN/clashN/Views/DashboardView.xaml)
4. Update DashboardViewModel.cs to expose the metric and refresh logic (clashN/clashN/ViewModels/DashboardViewModel.cs)

1. Dual-repo requirement: must clone both ClashN and v2rayN into same parent folder (not standard dependency management) — builds will fail if v2rayN not present as sibling. 2. Mihomo binary dependency: application expects Mihomo core executable; must be downloaded separately from MetaCubeX/Mihomo releases and placed in expected location (likely configurable in CoreInfo/CoreKind). 3. .NET 8.0 Desktop Runtime hard requirement: application won't run without exact runtime version installed; no forward/backward compatibility. 4. System proxy requires elevation: SysProxyHandle.cs likely requires admin privileges on Windows; UAC prompt expected on proxy changes. 5. Sysproxy.exe.gz bundled: compressed binary in Resources used by proxy handler; ensure extraction/decompression logic works on first run.

• Proxy chain configuration (outbound groups & rules) — ClashN's core function is managing Clash rule matching and proxy group selection; understanding how outbound groups chain and rules evaluate is essential to understanding what the config generation does
• YAML configuration serialization — CoreConfigHandler converts C# models into YAML that Mihomo parses; you'll frequently debug mismatched YAML formatting or invalid schema if modifying config generation
• Windows system proxy (WinINet / registry) — SysProxyHandle manipulates Windows proxy settings at the OS level; understanding PAC files and registry paths is required for system-wide proxy routing features
• Process lifecycle management (child process I/O redirection) — CoreHandler spawns and monitors Mihomo as child process; you must handle stdout/stderr capture, exit codes, and graceful shutdown to debug core failures
• Subscription format conversion (Clash, V2Ray, Trojan) — ConfigProc.cs converts multiple proxy protocol formats (V2Ray, Trojan) into Clash format; understanding subscription parsing is key to supporting new profile sources
• Data binding in WPF (XAML/MVVM-lite pattern) — UI updates are driven by property binding from Mode classes to XAML views; modifying data models requires understanding WPF change notification
• IL weaving with Fody — FodyWeavers.xml enables compile-time code injection (likely for property change notifications, logging, or optimization); modifying build pipeline requires understanding Fody configuration

• 2dust/v2rayN — Parent/successor project that clashN is being merged into; shares architecture and utilities; required as sibling repo during build
• MetaCubeX/Mihomo — The proxy core engine that clashN wraps; all actual proxy functionality runs here; users must download separately from this repo
• Dreamacro/clash — Original Clash project that Mihomo forks from; architectural reference for understanding config format and feature set
• comzyh/clash-windows — Alternative Clash Windows GUI using same core; comparable WPF approach for reference implementation
• neko-wenxuan/clash-nyanpasu — Modern Clash GUI using Tauri/Vue; shows alternative UI approach if considering future redesigns away from WPF

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for Handler/CoreConfigHandler.cs and Handler/CoreHandler.cs

The CoreHandler and CoreConfigHandler classes manage critical functionality for Mihomo core lifecycle (start/stop/restart) and configuration management. These are core to the application but have no corresponding test files. Adding tests would prevent regressions when modifying core behavior, especially important given the tight integration with the external Mihomo binary.

• [ ] Create clashN/clashN.Tests/Handler/CoreHandlerTests.cs with tests for core startup, shutdown, and restart scenarios
• [ ] Create clashN/clashN.Tests/Handler/CoreConfigHandlerTests.cs with tests for config loading, parsing, and validation
• [ ] Mock external Mihomo process calls using a testing framework (xUnit + Moq recommended for C#)
• [ ] Add test project reference to clashN.sln and configure test runner in CI

Add GitHub Actions workflow for automated builds and releases

The repository lacks CI/CD automation. Given that this is a .NET 8.0 WPF desktop application with multiple platform concerns (x86/x64), an automated build workflow would ensure release artifacts are consistently built, tested, and published. This is especially critical since users must download pre-built clashN.zip from releases.

• [ ] Create .github/workflows/build.yml to compile clashN.sln for both x86 and x64 platforms on Windows runners
• [ ] Add steps to run unit tests (once created) and validate that the application builds without warnings
• [ ] Create .github/workflows/release.yml to automatically create release artifacts (clashN.zip) on Git tags matching vX.Y.Z pattern
• [ ] Ensure artifacts include both architecture builds and required runtime dependencies documentation

Extract and document ProxySetting.cs and SysProxyHandle.cs system proxy logic into testable utility module

System proxy configuration (Handler/ProxySetting.cs and Handler/SysProxyHandle.cs) is a sensitive area that affects Windows network settings globally. Currently this logic is tightly coupled with the main application flow. Extracting this into a separate, well-tested utility library would enable safer changes, clearer error handling, and reusability across the project.

• [ ] Create new project clashN/clashN.SysProxy with extracted classes for WindowsProxyManager and SysProxyHelper
• [ ] Move resource files (sysproxy.exe.gz, sysproxy64.exe.gz from Resources/) into the new project and create resource extraction helpers
• [ ] Add comprehensive unit tests in clashN/clashN.Tests/SysProxy/ covering elevation checks, registry operations, and rollback scenarios
• [ ] Update Handler/ProxySetting.cs and Handler/SysProxyHandle.cs to use the new module, reducing ~200+ lines of code from main application

• Add unit tests for Base/StringEx.cs utility methods — currently no test files visible in structure, and string manipulation is critical for config parsing. Start with null/empty string edge cases.
• Document the Mihomo config schema mapping in Mode/Config.cs — add XML documentation comments explaining which properties map to which Clash config sections (rules, providers, outbound groups). This helps contributors understand the data model.
• Implement missing error handling in Handler/DownloadHandle.cs — add retry logic with exponential backoff for subscription downloads; currently likely has basic error reporting with no recovery mechanism.

Failed to generate security analysis.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.