Skip to content

Split the proxy core into a shared library, add a Linux CLI#9

Draft
svandragt wants to merge 1 commit into
stuartshields:mainfrom
svandragt:linux-cli-support
Draft

Split the proxy core into a shared library, add a Linux CLI#9
svandragt wants to merge 1 commit into
stuartshields:mainfrom
svandragt:linux-cli-support

Conversation

@svandragt

Copy link
Copy Markdown

Closes #8.

My first thought was just to check whether the existing package builds on Linux, but with everything in one target that was never going to work.

Changes

  • Split Package.swift into ProxyLightCore (portable library — mapping engine, PAC generation, CA/leaf cert generation, the SwiftNIO proxy pipeline, and a new ProxyOrchestrator extracted from AppState), the existing macOS app target, and a new proxylight-cli executable target.
  • macOS-only wrappers (SystemProxyManager, CATrustManager, SelfUpdater, LoginItemManager, ProxyRestoreStore) moved to Sources/ProxyLight/MacOS/. The macOS app's behaviour is unchanged — it now just depends on ProxyLightCore instead of owning everything directly.
  • proxylight-cli (swift-argument-parser) with start, mapping add/list/remove, import, export, ca-path.
  • Test suite split the same way: ProxyLightCoreTests (portable) and ProxyLightTests (macOS-only). ProxyLightCoreTests passes on Linux — 86/86, checked against the swift:6.1 Docker image.
  • Fixed a real bug along the way: the CLI's SIGINT/SIGTERM DispatchSource was scheduled on DispatchQueue.main, which never drains because the CLI blocks the main thread on a semaphore instead of running a run loop. Moved it to a dedicated queue.
  • README and CLAUDE.md updated for the new target split and Linux usage.

Scope

Linux CLI is deliberately minimal, per the issue: no system-proxy automation, no CA trust-store auto-install, no login-at-boot, no self-update. proxylight start prints the PAC URL and the CA cert path; the user points their browser at the URL and imports the cert by hand.

No CI job yet — Linux builds were checked manually via Docker, not wired into GitHub Actions.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Sg1MPNVjkvn53s8bgYdJD9

Splits Package.swift into ProxyLightCore (portable), the existing
macOS app target, and a new proxylight-cli target, extracting a
plain-Swift ProxyOrchestrator out of AppState so both frontends drive
the same start/stop/mapping logic. The CLI is minimal scope: proxy +
PAC + CA cert generation only, no system-proxy automation, no CA
trust-store install, no login-at-boot, no self-update on Linux.

Closes stuartshields#8.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Sg1MPNVjkvn53s8bgYdJD9
@svandragt
svandragt marked this pull request as draft July 10, 2026 09:39
@svandragt

svandragt commented Jul 10, 2026

Copy link
Copy Markdown
Author
  • I need to Test
  • change pr to ready

@stuartshields

Copy link
Copy Markdown
Owner

@svandragt Would this also work with Windows Powershell? I don't have a Windows laptop to try it out.

@svandragt

svandragt commented Jul 13, 2026

Copy link
Copy Markdown
Author

I would presume not. Windows and Linux are very different. There are free Windows VMs available on Microsoft's site but I'd open a separate issue for that for now, it's not in scope.

Powershell the terminal app can run Windows cli executables fine though. Powershell the scripting language has its own syntax so I don't think that's what you mean.

If you mean WSL then it might work. Also worth testing in a separate issue

@stuartshields

Copy link
Copy Markdown
Owner

@svandragt Yeah WSL is what I meant. I agree that we can test this in a different issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add a Linux CLI build alongside the macOS app

2 participants