lnwjud

Windows-first local AI-agent runtime and MCP gateway
223 configurable tools for local files, Git, processes, Windows automation, WSL, browser control, durable goal continuation, indexing, observability, and extensibility; 217 are advertised by default because codex_* delegation is opt-in.

What is lnwjud?

lnwjud is a Windows-first local development gateway that exposes trusted local capabilities through the Model Context Protocol (MCP). It is designed for AI-assisted software development where the agent needs more than a text-only chat: it may need to inspect a repository, search code, edit files, review Git state, run project commands, manage owned processes, inspect Windows UI state, automate a managed browser, work with WSL, or call an additional local MCP server.

The runtime stays on the Windows machine. Local filesystem paths, processes, SQLite state, credentials, and capability backends are owned by lnwjud on that machine. Remote AI clients only receive the MCP requests and results that travel through the connection mode you choose.

For ChatGPT web and other supported OpenAI surfaces, lnwjud supports the official OpenAI Secure MCP Tunnel. The tunnel is outbound-only: tunnel-client runs beside lnwjud, reaches OpenAI over outbound HTTPS, forwards MCP work to lnwjud's Desktop loopback HTTP MCP, and returns the response without opening a public inbound port on the Windows machine.

Current version: v4.11.0

The v4.11.0 release target and runtime contract contain 223 configurable MCP tools, with 217 advertised by default because the six codex_* delegation tools are opt-in. The earlier 184-tool snapshot remains only as the compatibility baseline used by the v4 architecture; new v4 gateway capabilities are additive.

What's new in v4.11.0

• Adds multiple simultaneous Active Projects for parallel ChatGPT chats/projects. One project remains Primary only as the fallback when a tool call omits workspaceId; explicit workspace-scoped calls stay isolated per project/session.
• Updates Recovery Center to render the full recovery/checkpoint history inside a fixed-height scroll area (roughly ten visible rows) and adds user-selectable automatic retention: Never, 7, 14, 30, 60, 90, 180, or 365 days. The safe upgrade default is Never.
• Bundles the official OpenAI tunnel-client v0.0.12 Windows x64 inside the lnwjud Windows packages. Packaging verifies the pinned release archive SHA-256 before inclusion; users only need to provide the Runtime API key and Tunnel ID. A manual executable path remains an advanced override/troubleshooting option.
• Adds a single-file lnwjud-Portable-4.11.0.exe alongside the NSIS installer for Windows 10/11 x64. Portable mode needs no installation and intentionally reuses the same per-user lnwjud settings/data location as the installed build.
• Hardens Windows 10/11 x64 compatibility: Windows 10 uses a conservative software-rendering profile to avoid blank/partially unclickable Chromium surfaces on older GPU drivers, while Windows 11 keeps hardware acceleration. Internal Windows child processes remain hidden and use built-in Windows PowerShell where product plumbing needs PowerShell; durable shell workers are capped at 16 concurrent tasks and managed process handles at 24 to prevent runaway conhost.exe/CPU growth when many chats run work in parallel.
• Adds distribution-aware automatic updates. Installed builds stay on latest.yml and update with lnwjud-Setup-<version>.exe; Portable builds use the separate portable.yml channel and update with lnwjud-Portable-<version>.exe. Portable replacement waits for the running process to exit, backs up the current EXE, replaces that exact Portable path, rolls back on failure, and restarts it. Auto-update never switches a user from Portable to Installer or vice versa.
• Adds Durable Goal Continuation with run_goal, get_goal, checkpoint_goal, finish_goal, and list_goals. Goal state survives runtime/session interruptions in SQLite, uses append-only checkpoints plus revision compare-and-swap, stores only SHA-256 lease-token hashes, and persists active task IDs so a resumed turn can inspect existing work instead of repeating it.
• Improves Tunnel Settings spacing so status, warning, action, and evidence blocks are visually separated.
• Removes the former 22-minute Budget Guard that appended a handoff/background instruction to tool results. MCP initialization now advertises an outcome-driven contract: ChatGPT keeps using lnwjud until the requested result is complete and never stops merely because elapsed time passed.
• Adds a Persistent OpenAI Tunnel Runtime around the official tunnel-client runtimes lifecycle. lnwjud saves one tunnel identity, uses runtime alias lnwjud, and reconciles that same tunnel_id back to the current Desktop loopback MCP URL instead of creating replacement tunnels.
• Lets a supported native tunnel runtime survive a short Desktop restart gap. On the next launch, Desktop MCP starts first and the reconciler rebinds the same remote tunnel identity even when the local ephemeral MCP port changes.
• Reconnects transient runtime/control-plane failures indefinitely with capped backoff instead of permanently giving up after a fixed rapid-exit count. Authentication and operator-action failures fail closed without a tight retry loop; repairing the runtime key resumes the same saved tunnel identity.
• Adds persistent tunnel status and controls to Settings plus Doctor checks for identity, runtime process, health, readiness, control-plane polling, local MCP reachability/binding, tunnel-ID mismatch, and runtime-key availability. Tunnel IDs are masked and secrets are never included in status/log evidence.
• Adds deterministic continuity acceptance for runtime death, Desktop restart/rebind, short and >5-minute transient outages, revoked-key recovery, tunnel-ID mismatch, durable task resilience, and the 2026-07-28 MCP protocol catalog. The v4.11 catalog is 217 tools by default and is byte-stable across a Desktop MCP listener restart.
• Keeps the release claim capability-gated: the installed official tunnel client supports managed runtimes plus health/readiness/poll gates, but does not expose a proven ready-before-retire overlap primitive. v4.11 therefore does not claim strict zero downtime; it truthfully provides persistent same-ID reconnect continuity without requiring a VPS, public domain, or Cloudflare relay.

What's new in v4.10.0

• Replaces blanket mutation prompts with a typed, action-level policy. Full Access runs ordinary read/write/edit/replace/execute, Git, shell/process, Codex, Office/UI and remote mutations without confirmation; prompts are reserved for detected deletion/data-loss operations, destructive rewrites, and explicit Active Project escapes, while hard-blocked machine-level actions remain denied.
• Binds local mutations to the host-selected Active Project. A request-supplied workspace ID cannot widen authority. Full Access keeps ordinary work non-interactive, while destructive delete_file, Git, shell, and WSL families may use saved auto-approval only for exact targets proven inside the Active Project; broad, critical, ambiguous, or escaped forms still ask or fail closed.
• Makes file replacement reversible: existing text writes/patches/edits create checkpoints, Office/DOCX/PowerPoint binary replacements create byte-for-byte Recovery Trash backups, and restoring a replacement backup first preserves the current version as an Undo item.
• Makes direct file operations recoverable without making Full Access noisy: Safe/Balanced retain conservative replacement rules, while Full can write_file, apply_patch, edit, copy, move, and replace ordinary targets without prompts. Existing content is checkpointed/backed up where supported, and deletion remains limited to one file or one empty directory.
• Applies the same profile-aware mutation classifier across Git, shell/WSL, process/Codex, Office, scheduler, HTTP mutations, browser/UI actions, and Windows-native side effects, so Full does not receive duplicate backend prompts for ordinary work. Destructive actions are never automatically retried.
• Adds a Recovery Center that shows the real local Recovery Trash path, deleted items, pre-replacement binary backups, checkpoints, and rollback IDs. Critical-path deletion remains guarded; ordinary Full-profile edits/replacements use recovery/checkpoint protections without an extra prompt.
• Synchronizes the live catalog at 223 configurable tools / 217 advertised by default, including Durable Goal Continuation and the recovery/checkpoint tools, and makes README catalog drift a generated release-check failure.

What's new in v4.9.1

• Adds first-class project lifecycle management in the Desktop Projects page: active projects can be archived, archived projects can be restored, and project registrations can be removed with a two-step confirmation.
• Treats archived workspaces as inactive trust-boundary entries: they remain in SQLite for management/history labels but are excluded from normal runtime/MCP workspace lookup until restored.
• Makes project removal registration-only. Removing a project from lnwjud does not delete its directory, files, Git repository, audit history, or checkpoints; system/machine-root workspaces are protected from archive/remove actions.
• Repairs selected-workspace state after archive/removal, stops the workspace index watcher, blocks lifecycle changes while tracked Desktop work is active, and restores an archived registration instead of creating a duplicate when the same path is added again.
• Keeps Home/Git selectors limited to active workspaces while Projects, Work Log, and Live Logs retain the management/history context needed to understand archived workspaces.

What's new in v4.9.0

• Adds real multi-workspace / multi-session operation on one lnwjud installation: Desktop workspace selection no longer restarts the MCP listener, HTTP/STDIO sessions have stable ownership boundaries, and process/Codex/shell/WSL/task handles are isolated by session and workspace.
• Makes destructive authorization request-scoped instead of relying on the Desktop-selected project, while keeping destructive auto-approval disabled by default, preserving Protected Critical Files, and supporting recoverable delete/restore.
• Makes shared activity and durable runtime state safe for concurrent owners with per-owner activity leases, session-namespaced state, atomic writes, inter-process locking, shared plugin/worktree ledgers, and fail-closed checkpoint persistence under I/O contention.
• Propagates workspace/session metadata through audit, Work Log, Live Logs, and process feeds; adds workspace/session filters, badges, scoped clear controls, and filtered log export without splitting global settings.
• Adds real two-session/two-workspace release acceptance and release-gate coverage, including parallel build/test/background/Git workflows, handle isolation, updater safety, packaging, and Windows installer verification.
• Fixes Work Log attribution for shell calls from clients with an older/stale schema: a registered workspace is inferred from cwd for logging only, and the task workspace is retained for later wait/status/logs/result/cancel activity without weakening permission or path policy.

What's new in v4.8.5

• Adds two user-configurable wait controls under Settings → Tools & Timeouts. MCP Poll / Tool Wait is adjustable from 5–60 seconds with a 5-second default, while Foreground Shell Wait is adjustable from 5–60 seconds with a 60-second default. Both limits are validated by the desktop IPC boundary and persisted in the local SQLite settings store.
• v4.8.5 originally applied both wait settings to the Desktop HTTP runtime and the then-shared direct STDIO / Secure Tunnel runtime. In v4.10.0 Secure Tunnel moved to the Desktop HTTP MCP; standalone/headless STDIO keeps its own runtime policy while shell and MCP polling continue to read the configured wait values.
• Uses the same configurable MCP poll window for experimental tasks/result and advertised task pollInterval, while preserving the durable background-task contract: reaching the wait limit never kills the command running on the machine.
• Strengthens agent guidance for long-running work: after one or two checks still report running, preserve the task ID and return control instead of tight-polling inside one ChatGPT turn. This reduces message-delivery timeouts without losing the background build, test, install, or packaging task.

What's new in v4.8.4

• Makes MCP command execution non-blocking by policy: shell and wsl_exec run requests are normalized to durable background execution and return a task handle immediately, while MCP wait polling is capped at 5 seconds. Long builds, tests, installs, and packaging jobs therefore keep running on the machine instead of holding one ChatGPT/MCP tool request open until it times out.
• Keeps the core ShellCapabilityBackend independent from that transport policy. Direct/internal foreground callers retain the 60-second synchronous wait ceiling; regression coverage verifies a foreground command running beyond 5 seconds still returns its terminal result normally.
• Bounds experimental MCP Tasks tasks/result to a short ~5-second request window. Non-terminal tasks direct clients back to tasks/get polling, while durable task state, logs, cancellation, and later result retrieval continue across runtime runs.
• Clarifies immediate-return process_start and project_* contracts, updates the live catalog to 214 configurable tools (208 advertised by default because the six codex_* delegation tools are opt-in), and synchronizes the README, architecture, packaging, and release metadata for v4.8.4.
• Documents the separately configurable STDIO permission profile and optional Strict Roots while preserving the backward-compatible full profile default.

What's new in v4.8.3

• Hardened the real desktop MCP E2E flow for hosted Windows runners by allowing the managed project-test process up to 60 seconds to publish its terminal status. The test already has a 180-second scenario budget; this change only removes the overly strict 15-second inner poll and keeps the same terminal state assertions.
• Keeps the v4.8.2 canonical-path fix and targeted Vitest timeout budgets intact; no runtime permission, process, or MCP behavior is relaxed by this patch.

What's new in v4.8.2

• Hardened the v4.8 release line for clean Windows CI/release runners: document workspace-boundary checks now compare canonical paths so Windows 8.3 aliases do not produce false outside-workspace failures while junction/symlink escapes remain rejected.
• Increased the Vitest budget only for the three process/I/O-heavy smoke and integration tests that legitimately exceed the 5-second default on hosted Windows runners. Performance assertions remain separate and unchanged.
• Version metadata, packaging assertions, installer naming, and the generated 213-tool runtime contract are synchronized to 4.8.2.

What's new in v4.8.0

• Durable background tasks (shell/wsl_exec execution=background) are exposed through the experimental MCP Tasks utility (spec 2025-11-25): tasks/get, tasks/result, tasks/list, and tasks/cancel, advertised as capabilities.tasks { list, cancel }. Task creation stays with the shell tool; task-augmented tools/call is intentionally not declared yet. See docs/mcp/MCP_TASKS.md for the state mapping and known deviations.
• Wave 3: the WinRT OCR helper gained build/sign/register scripts (scripts/build-windows-ocr.ps1, scripts/register-windows-ocr.ps1 with a self-signed dev path), real cached host-side identity probing, packaging assets, and installer shipping (windows-ocr extra resource).
• Wave 5: event_watch/crash_trace serve bounded allowlisted Get-WinEvent queries; sandbox_exec stages the artifact-only WSB plan, launches WindowsSandbox.exe, and retrieves stdout/stderr/exit-code behind dry-run and confirmation gating.
• Wave 6: read-only SQLite db_inspect/db_query (workspace-confined, single SELECT/PRAGMA), a minimal stdio LSP client behind lsp_diagnostics/lsp_rename (LNWJUD_LSP_<LANGUAGE>_COMMAND), and a persisted Git worktree ownership ledger with git_worktree_remove. DAP stays contract-only by design.
• Wave 7: PowerPoint read/save_as and read-only Outlook folder/message headers joined the Office COM boundary; pdf_extract_tables/inspect_pdf run through an optional local PDF provider; docx_merge and inspect_workbook use Word/Excel COM; the phase-37 compare/preview adapters now report truthful optional availability.
• Wave 8: self_heal_plan proposes allowlisted reversible fixes from live evidence and self_heal_apply executes them behind dry-run + explicit confirmation with no automatic destructive retry. agent_swarm_run remains planned (the only local subagent provider is Codex, which the chat-quota-only policy keeps off-limits).

What's new in v4.7.1

• Resilient long-session workflows for chat-quota runs: a run budget guard appends near-limit warnings to tool results, session_handoff builds a same-chat continuation prompt from the tracker, Git state, and durable task IDs, and verify_incremental caches typecheck results keyed by the Git diff.
• Codex delegation tools (codex_*) are disabled unless explicitly enabled, keeping the separate Codex work quota untouched. The long-session guide is docs/CHATGPT_LONG_SESSION.md.

What's new in v4.7.0

• End-user configuration: the desktop Settings page gained a user config panel with persisted preferences, plus tray, tunnel-controller, and update-check scheduler refinements backed by new persistence tests.

What's new in v4.6.0

• Durable background command tasks decouple long-running Windows work from a single MCP tool-call lifetime. Background tasks can survive MCP/stdio runtime replacement and are recovered by task ID for status, logs, result, or cancel.
• Selectable standalone/headless STDIO permission profiles (safe, balanced, full, or custom) plus opt-in Strict Roots. The compatibility default remains full with existing machine roots until Strict Roots is enabled. v4.10.0 routes Secure Tunnel through the Desktop HTTP MCP instead, so remote tunnel calls use the Desktop permission profile, Active Project, and native approval.
• Historical v4.6.0 introduced per-command-family AI Destructive Actions toggles. That model is superseded in v4.10.0: only the exact recoverable delete_file operation can be scoped auto-approved. Git, shell, and WSL destructive forms are never toggle-auto-approved; they are blocked by command policy or remain opaque mutations requiring current chat confirmation and independent host exact-action approval.
• Checkpoint file payloads are encrypted at rest with AES-256-GCM. The local encryption key is protected with Windows DPAPI, and legacy plaintext checkpoint rows are upgraded to ciphertext as the encrypted repository starts.
• SQLite-consistent automatic backup/restore with daily and weekly retention, pre-migration/pre-update snapshots, cross-process backup coordination, and restart-safe restore handling.
• PowerShell hardening adds -NonInteractive to internal launches and verifies the packaged Windows capability bridge SHA-256 before every execution.
• Live Logs and Work Log now use newest-first bounded tables, filtering/search, full-entry copy actions, clear-all handling, improved pop-out behavior, and clearer MCP TASK/RESULT/ERROR presentation.
• Desktop dependencies were refreshed within compatible release lines to Electron 43.4.1 and Vite 7.3.6 without migrating to electron-vite.

Current v4 highlights include:

• Workspace registration, bounded project snapshots, file reads/writes, paging, full scans, persistent indexing, and continuation tokens.
• Git status/diff/log plus policy-checked Git execution.
• Foreground/background command tasks with ownership, timeout, cancellation, bounded output, logs, and result retrieval.
• Project-aware development, test, lint, typecheck, and build commands.
• Local Codex discovery and optional delegation without reading Codex credential files.
• Native Windows capabilities for shell execution, windows, accessibility, input, screen capture, notifications, clipboard, file dialogs, audio, screen recording, Office automation, and scheduler integration.
• Managed Chrome / CDP automation and Set-of-Marks annotated observations with expiring observation hashes and approval-gated target actions.
• Scoped WSL execution and Windows/WSL path translation for registered workspaces.
• Skills discovery plus child MCP discovery/description/call contracts.
• Compound and parallel workflows, deterministic semantic tool routing, and Context Economy telemetry.
• Trace-correlated activity, NDJSON/SQLite audit metadata, Work Log, Live Logs, Doctor checks, health surfaces, and background tray operation.
• OpenAI Secure MCP Tunnel management with Windows DPAPI-encrypted runtime-key storage and reconnect handling.

Authoritative in-repository references:

• Tool contract — core primitive schemas, policy classes, and compatibility rules; the 223-tool configurable index below comes from the live runtime registry.
• Upgrade architecture — v4 runtime architecture and additive gateway design.
• Roadmap phase status — completed implementation phases.

Security model you should understand before using it

lnwjud is intentionally powerful. It is intended for a machine and workspace you trust, not as a sandbox for unknown code.

• Unrestricted mode is enabled by default for read/discovery compatibility. Fixed local drives can be registered as machine roots and inspected by the local-agent runtime. Unrestricted mode does not widen the host-selected Active Project mutation boundary, bypass command policy, or bypass trusted host approval.
• Desktop MCP applies the selected permission profile (safe, balanced, full, or custom) to tool calls.
• The packaged standalone/headless STDIO runtime supports selectable safe, balanced, full, or custom profiles. For backward compatibility the default remains full with the existing machine-root behavior until Strict Roots is enabled. Secure Tunnel does not use this headless profile; it uses the running Desktop MCP permission profile and the Desktop-selected Active Project.
• Strict Roots is opt-in and limits standalone/headless STDIO workspace visibility to explicitly allowed roots. It is a filesystem/capability boundary, not an operating-system sandbox. Secure Tunnel remains constrained by the Desktop Active Project mutation boundary and native exact-action approval.
• Explicit file reads can include sensitive files such as .env when the active policy permits them. Do not register or expose a machine to an AI client you do not trust.
• Destructive and opaque operations are centrally classified. Approval-required mutations need explicit chat confirmation and an independent trusted host exact-action approval before backend dispatch. The Desktop native dialog is cancel-first; standalone/headless runtimes without a trusted host approval provider fail closed instead of silently approving.
• The exact delete_file operation is the only mutation eligible for scoped auto-approval, and only after the target is proven recoverable inside the Active Project. Protected critical paths, workspace roots, non-empty directories, unsafe/broad patterns, outside paths, and reparse/junction escapes are never auto-approved.
• Recovery Center derives and displays the local Recovery Trash path from the configured Desktop data root (<dataRoot>/recovery-trash). Replacement backups and supported deletes are recorded there or in encrypted checkpoints before the authoritative mutation where the operation is recoverable.
• Arbitrary approved commands, package scripts, project-owned scripts, Codex instructions, child MCP calls, and remote mutations are opaque execution. They are not an operating-system sandbox and are not automatically recoverable through Recovery Trash.
• Disk formatting and machine shutdown/reboot remain hard-blocked by the capability policy.
• The local Streamable HTTP MCP endpoint binds to loopback. Do not publish that loopback endpoint through a generic reverse proxy. For a private remote connection, use Secure MCP Tunnel.
• Runtime tunnel API keys saved from the desktop UI are encrypted with Windows DPAPI for the current Windows user. Never commit a runtime key, .env, tunnel profile containing a plaintext secret, private key, or credential file.

The Context Economy Engine reduces automatic discovery cost without acting as a security deny list. Automatic search/index/watch flows skip vendor, build, cache, binary, generated-bundle, and source-map noise, while explicit reads or full scans can still inspect paths allowed by the active workspace/policy.

Connection modes

The desktop HTTP server starts automatically after lnwjud resolves a workspace. If the preferred port 18765 is busy, the server can fall back to an ephemeral loopback port; always use the endpoint shown in the dashboard. The Start Connection button is useful after a manual stop, while Stop Connection stops the current local HTTP listener.

Quick start: install the Windows release

1. Install lnwjud Desktop

1. Download the latest published installer from GitHub Releases. Current Windows 10/11 x64 artifacts are lnwjud-Setup-4.11.0.exe (recommended installer) and lnwjud-Portable-4.11.0.exe (no installation required).
2. Run the NSIS installer and launch lnwjud Agent Control Center.
3. Add or select the project/workspace you want lnwjud to operate on.
4. Review Settings before attaching an AI client, especially Permission Profile and Unrestricted Mode.

If you prefer not to install the app, run lnwjud-Portable-4.11.0.exe directly. Portable mode uses the same per-user lnwjud data/settings location as the installer; it is a portable executable, not a keep-all-data-next-to-the-EXE mode. Automatic updates preserve the distribution you chose. Installer users read latest.yml and receive the next lnwjud-Setup-<version>.exe. Portable users read portable.yml and receive the next lnwjud-Portable-<version>.exe, which is verified by the updater and then replaces the same Portable EXE path with a backup/rollback/restart flow after the running process exits. The updater never converts a Portable install into an Installer install or the reverse.

The graphical desktop app and the packaged local STDIO launcher are self-contained. Both Windows packages ship Electron for the dashboard and a private Node.js 24 runtime for lnwjud-mcp-stdio.cmd, so end users do not need a separate system Node.js installation. Secure Tunnel uses the running Desktop HTTP MCP plus the bundled official tunnel-client.exe; it does not spawn the packaged STDIO launcher.

2. Prepare OpenAI Secure MCP Tunnel for ChatGPT web

OpenAI's Secure MCP Tunnel flow requires a Platform tunnel ID and a runtime API key. The published Windows x64 installer and portable executable already contain the official OpenAI tunnel-client v0.0.12, so release users do not download or extract a separate tunnel-client package. Creating or editing a tunnel requires Tunnels Read + Manage; the runtime key needs Tunnels Read + Use.

1. Open OpenAI Platform tunnel settings.
2. Create a tunnel named lnwjud and associate it with the Platform organization that owns it and the ChatGPT workspace that should use it.
3. Create a restricted runtime API key with Tunnels Read + Use.
4. Open lnwjud → Settings → OpenAI Secure MCP Tunnel. Save the runtime API key, leave the tunnel-client (bundled) override field empty, paste the tunnel ID, and click Configure Tunnel.
5. The Setup Wizard selects the bundled client automatically, starts or reuses lnwjud's Desktop loopback HTTP MCP, creates or repairs %APPDATA%/tunnel-client/lnwjud.yaml, and runs the required tunnel diagnostics. Secure Tunnel does not spawn a separate headless lnwjud MCP runtime, so the Desktop-selected Active Projects and native exact-action approval remain authoritative for remote ChatGPT calls.

The tunnel-client path field is an override/troubleshooting control only. Clear it and choose Use bundled to return to the package-supplied client. Source builds may prepare the pinned client during package:windows; that build step is not an end-user installation step.

If you intentionally need to initialize the profile by hand, keep lnwjud running and copy the Local MCP endpoint shown by lnwjud (it is loopback-only and ends in /mcp):

$env:CONTROL_PLANE_API_KEY = '<runtime-key-for-this-session>'
$tc = 'C:/path/to/tunnel-client.exe'
$profileDir = Join-Path $env:APPDATA 'tunnel-client'
$mcpEndpoint = 'http://127.0.0.1:<port>/mcp' # copy the actual endpoint shown by lnwjud

& $tc init `
  --force `
  --sample sample_mcp_remote_no_auth `
  --profile lnwjud `
  --profile-dir $profileDir `
  --tunnel-id 'tunnel_0123456789abcdef0123456789abcdef' `
  --control-plane-api-key-ref 'env:CONTROL_PLANE_API_KEY' `
  --health-listen-addr '127.0.0.1:0' `
  --mcp-server-url $mcpEndpoint

& $tc doctor --profile lnwjud --profile-dir $profileDir --explain
Remove-Item Env:CONTROL_PLANE_API_KEY -ErrorAction SilentlyContinue

3. Save tunnel settings in the desktop UI

In Settings → OpenAI Secure MCP Tunnel:

1. Save the runtime API key. lnwjud encrypts it locally with Windows DPAPI. The generated tunnel profile stores only the reference env:CONTROL_PLANE_API_KEY, never the literal runtime key.
2. Leave the tunnel-client override field empty to use the official tunnel-client v0.0.12 bundled with the Windows x64 installer. Browse/save a custom executable only when intentionally overriding it for troubleshooting.
3. Paste the OpenAI tunnel ID and click Configure Tunnel. The wizard replaces or repairs the lnwjud-owned profile so mcp.server_urls points to the Desktop loopback MCP endpoint and control_plane.api_key is the environment reference.
4. After Configure Tunnel succeeds, confirm %APPDATA%/tunnel-client/lnwjud.yaml exists and click Start Tunnel.
5. Open Live Logs or run Doctor if the tunnel fails to start.

The desktop tunnel controller repairs stale stdio profiles into Desktop HTTP profiles before Doctor/Start, runs tunnel-client doctor before launch, starts the client with a seven-day MCP connection ceiling, detects externally started lnwjud tunnel processes, and performs bounded reconnect attempts after unexpected exits. If an older profile contains commands:, a build-machine path such as D:/lnwjud/lnwjud-mcp-stdio.cmd, or a literal control_plane.api_key, Configure Tunnel/Start Tunnel repairs it to the current Desktop loopback /mcp endpoint and the env:CONTROL_PLANE_API_KEY secret reference before Doctor/Run.

4. Add lnwjud to ChatGPT

For current ChatGPT developer-mode MCP testing, use the official Connect and test your plugin guide as the UI source of truth because workspace policy and labels can change. The stable flow is:

1. Enable Developer mode for the target ChatGPT account/workspace if your plan and workspace policy allow it.
2. Open ChatGPT Plugins and select the plus button.
3. Enter a name/description, choose Tunnel under Connection, and select the associated lnwjud tunnel or enter its tunnel_id.
4. Create the connection and review the discovered tools and metadata.
5. Confirm that the default runtime exposes 217 tools (or 223 when Codex delegation is explicitly enabled) and run a read-only smoke test before trying writes.

Example smoke test:

Use lnwjud to list registered workspaces, report Git status for the selected project, and summarize the top-level project tree. Do not modify anything.

Quick start: install the Windows release (ภาษาไทย)

ส่วนนี้สำหรับผู้ใช้ Windows ที่ต้องการติดตั้ง lnwjud แล้วเชื่อมกับ ChatGPT ผ่าน OpenAI Secure MCP Tunnel แบบง่ายที่สุด โดย ไม่ต้องติดตั้ง Node.js เพิ่ม Secure Tunnel จะส่งงานเข้าที่ Desktop loopback HTTP MCP ของ lnwjud โดยตรง ส่วน private Node runtime ที่มากับตัวติดตั้งยังคงใช้สำหรับ local stdio เช่น Codex CLI

1. ติดตั้ง lnwjud หรือใช้ Portable

1. แบบแนะนำ: ดาวน์โหลด lnwjud-Setup-4.11.0.exe แล้วติดตั้งตามปกติ
2. ถ้าไม่ต้องการติดตั้ง: ดาวน์โหลด lnwjud-Portable-4.11.0.exe แล้วเปิดได้ทันที
3. เปิด lnwjud Agent Control Center
4. เพิ่มหรือเลือก Project/Workspace ที่ต้องการให้ ChatGPT ทำงานด้วย

Portable ใช้ Settings/ข้อมูลต่อผู้ใช้ Windows ชุดเดียวกับตัวติดตั้ง ไม่ได้เก็บ database/settings ทุกอย่างไว้ข้าง EXE

2. สร้าง OpenAI Tunnel และ Runtime API key

1. เข้า OpenAI Platform tunnel settings
2. สร้าง Tunnel ใหม่และจดค่า tunnel_id ไว้
3. สร้าง Runtime API key ที่มีสิทธิ์ Tunnels Read + Use
4. เก็บ key ไว้เป็นความลับ ห้ามใส่ใน Git, README, issue หรือไฟล์ที่จะแชร์

3. tunnel-client มากับตัวติดตั้งแล้ว

ถ้าใช้ lnwjud-Setup-4.11.0.exe หรือ lnwjud-Portable-4.11.0.exe บน Windows x64 ไม่ต้องดาวน์โหลด tunnel-client.exe เอง ตัว release รวม official OpenAI tunnel-client v0.0.12 มาให้และ lnwjud จะเลือกใช้ให้อัตโนมัติ

ช่อง path ของ tunnel-client ใน Settings เป็น override สำหรับ troubleshoot เท่านั้น ปล่อยว่างไว้สำหรับการใช้งานปกติ หากเคย override แล้วต้องการกลับมาใช้ ตัวที่มากับโปรแกรม ให้ล้างช่องแล้วกด ใช้ตัวที่มากับโปรแกรม / Use bundled

4. ตั้งค่า Tunnel ใน lnwjud

เปิด Settings → OpenAI Secure MCP Tunnel แล้วทำตามลำดับนี้:

1. ใส่ Runtime API key แล้วกด Save key
2. ปล่อยช่อง tunnel-client override ว่างไว้ โปรแกรมจะใช้ tunnel-client v0.0.12 ที่มากับ installer อัตโนมัติ
3. ใส่ OpenAI Tunnel ID
4. กด Configure Tunnel
5. รอให้ Configure/Doctor ผ่าน
6. กด Start Tunnel หรือ Reconnect Tunnel เดิม ตามสถานะที่แสดง ใช้ Browse... เฉพาะกรณีต้องการ override executable เพื่อ troubleshooting

ตรงนี้ ไม่ต้องพิมพ์ path ของ lnwjud-mcp-stdio.cmd เอง โปรแกรมจะ เปิด/ใช้ Local MCP ของ Desktop แล้วสร้างหรือซ่อม %APPDATA%\tunnel-client\lnwjud.yaml ให้ mcp.server_urls ชี้ไปที่ http://127.0.0.1:<port>/mcp อัตโนมัติ และบังคับให้ control_plane.api_key เป็น env:CONTROL_PLANE_API_KEY แทนการเก็บ key จริงใน YAML

ถ้าเคยใช้รุ่นเก่าแล้ว YAML ค้าง commands:, path เช่น D:/lnwjud/lnwjud-mcp-stdio.cmd / E:/lnwjud/lnwjud-mcp-stdio.cmd หรือมี Runtime API key จริงอยู่ใน control_plane.api_key ให้กด Configure Tunnel ใหม่ โปรแกรมจะเปลี่ยน profile เป็น Desktop HTTP และ secret reference ให้เอง

5. เชื่อม Tunnel เข้ากับ ChatGPT

1. เปิด Developer mode ของ ChatGPT ถ้าบัญชี/Workspace รองรับ
2. เปิดหน้า Plugins/Connections ของ ChatGPT แล้วกดเพิ่ม connection
3. เลือก Connection แบบ Tunnel
4. เลือก tunnel ที่สร้างไว้ หรือใส่ tunnel_id
5. สร้าง connection แล้วตรวจว่าเห็น tools ของ lnwjud
6. ถ้าเพิ่งแก้ Tunnel หรืออัปเดต lnwjud ให้กด Refresh connector ก่อน ถ้ายัง stale ค่อยเปิดแชทใหม่

6. ทดสอบแบบ Read-only ก่อน

ลองสั่ง ChatGPT ก่อนด้วยงานที่ไม่แก้ไฟล์ เช่น:

Use lnwjud to list registered workspaces, show Git status for the selected project, and summarize the top-level project tree. Do not modify anything.

ถ้าคำสั่งนี้ทำงานได้ แปลว่า ChatGPT → OpenAI Tunnel → tunnel-client → lnwjud Desktop HTTP MCP เชื่อมต่อครบแล้ว จากนั้นจึงค่อยลองงานเขียนไฟล์หรือ คำสั่งที่ต้องมี native approval ใน Desktop

Quick start: build from source

Requirements for source development:

• Windows x64.
• Node.js >=24.0.0 <25.
• Git.
• Corepack with the repository-pinned pnpm@10.15.0.
• PowerShell 7 recommended; Windows PowerShell 5.1 is sufficient for most helper scripts.
• rg (ripgrep) recommended.

git clone https://github.com/engasnm111/lnwjud.git
Set-Location .\lnwjud
corepack enable
corepack pnpm@10.15.0 install --frozen-lockfile
Copy-Item .env.example .env

corepack pnpm@10.15.0 build

# Launch the development desktop runtime
corepack pnpm@10.15.0 desktop

Optional Windows installer build:

corepack pnpm@10.15.0 package:windows

The generated x64 NSIS installer is written under apps/desktop/dist/installers/.

Run in the Windows system tray

Closing the main lnwjud window hides it instead of shutting down the desktop runtime. The MCP listener, Live Logs, tunnel controller, and background services continue running and the lnwjud icon remains in the Windows notification area. Use the tray menu to reopen the dashboard, check for updates, or quit the process completely.

The packaged stdio launcher

lnwjud.exe is the graphical desktop entrypoint. Direct local STDIO clients such as Codex CLI should use the generated launcher below. Secure MCP Tunnel does not use this launcher; it forwards to the Desktop loopback HTTP MCP:

lnwjud-mcp-stdio.cmd --workspace D:\projects\my-app

The build generates lnwjud-mcp-stdio.cjs, lnwjud-mcp-stdio.cmd, and a private lnwjud-node.exe copied from the pinned Node.js 24 build runtime. These generated runtime files are intentionally ignored by Git. The Windows package copies them next to the installed application and into its resources directory, and the launcher uses only this bundled runtime rather than a system Node installation or PATH.

STDIO permission profiles and strict roots

The packaged stdio launcher keeps the historical behavior by default: the permission profile is full and machine-drive roots are registered as before. You can opt into a narrower policy per launch:

lnwjud-mcp-stdio.cmd --workspace D:\\projects\\my-app --profile safe --strict-roots --allowed-root D:\\projects\\my-app

Supported direct-stdio profiles are safe, balanced, full, and custom. Equivalent environment variables are LNWJUD_STDIO_PROFILE, LNWJUD_STRICT_ROOTS, and semicolon-separated LNWJUD_ALLOWED_ROOTS. OpenAI Secure MCP Tunnel does not use the headless stdio policy; it uses the running Desktop MCP permission profile, Active Project, and native host approval. In strict-root mode lnwjud skips automatic whole-drive registration and exposes only explicitly allowed canonical roots; absolute paths outside those roots fail closed. Existing realpath/reparse-point and secret-policy checks still apply. Strict roots are a filesystem/capability boundary, not an OS sandbox: spawned programs still run under the Windows user token.

The AI Destructive Actions setting is now deliberately narrow. Only the exact delete_file operation can be scoped auto-approved, and only when its saved policy is enabled, the target matches the host-selected Active Project, Recovery Trash is available, and the target is not a protected critical path, workspace root, non-empty directory, unsafe/broad pattern, outside path, or reparse escape. Git deletion/discard, shell/WSL deletion, process/project/Codex execution, child MCP calls, Office/native mutations, and remote mutations are never toggle-auto-approved. Approval-required actions need explicit chat confirmation plus independent trusted host exact-action approval; the Desktop dialog is cancel-first, while standalone/headless runtimes without a trusted provider fail closed. Recovery Center derives and displays the local Recovery Trash path from the configured data root (<dataRoot>/recovery-trash). Approved arbitrary commands/scripts remain opaque execution rather than an OS sandbox and are not automatically recoverable through Recovery Trash.

Requirements and optional integrations

Core requirements

• Windows x64.
• Node.js 24.x for source development/builds. Installed releases bundle their own private Node 24 runtime for direct local STDIO; Secure Tunnel uses the Desktop HTTP MCP and official tunnel-client.
• Git/Corepack/pnpm for source development.

Optional dependencies

• Codex CLI for codex_* delegation tools.
• rg for fast code search; lnwjud has bounded fallbacks where supported.
• Chrome/Chromium for managed CDP/browser capabilities.
• WSL for wsl_exec and wsl_fs.
• Microsoft Office applications for Office automation actions that require the native Office stack.
• FFmpeg and other media helpers for capabilities that report them as available.

OpenAI / ChatGPT requirements for Secure MCP Tunnel

• An OpenAI Platform organization with tunnel access.
• A tunnel associated with the intended Platform organization and ChatGPT workspace.
• Tunnels Read + Manage to create/edit a tunnel.
• Tunnels Read + Use to run tunnel-client or select a tunnel in the ChatGPT app flow.
• ChatGPT Developer mode access according to the target plan/workspace policy.
• Outbound HTTPS from the Windows host to api.openai.com:443 (or the documented mTLS control-plane host when configured).
• No inbound firewall rule or public lnwjud MCP port is required for Secure MCP Tunnel.

Install from source

Clone and install dependencies

git clone https://github.com/engasnm111/lnwjud.git
Set-Location .\lnwjud
corepack pnpm@10.15.0 install --frozen-lockfile

Do not silently upgrade the package manager: the lockfile is pinned to pnpm@10.15.0.

Configure Environment

Copy-Item .env.example .env

Build and run the desktop dashboard

One command from the repository root:

Set-Location .\lnwjud
corepack pnpm@10.15.0 desktop

This builds the desktop app and opens the Agent Control Center. MCP HTTP auto-starts on launch (no Start Connection click required). The dashboard owns the SQLite state, workspace registry, permission profile, work-log audit records, loopback MCP lifecycle, and Secure Tunnel controls.

Optional environment:

$env:LNWJUD_DATA_PATH = "$env:LOCALAPPDATA\lnwjud"
$env:LNWJUD_WORKSPACE = "D:\projects\my-app"
corepack pnpm@10.15.0 desktop

Use the same LNWJUD_DATA_PATH for desktop UI and the packaged stdio launcher so ChatGPT tool activity appears in the Work Log. The launcher is the same direct MCP entrypoint used by the Codex/tunnel integration.

Build Windows installer + portable executable

Set-Location .\lnwjud
corepack pnpm@10.15.0 package:windows

The Windows 10/11 x64 artifacts are written to:

apps/desktop/dist/installers/lnwjud-Setup-4.11.0.exe
apps/desktop/dist/installers/lnwjud-Portable-4.11.0.exe

The installer is per-user by default. The portable executable needs no installation but uses the same per-user lnwjud data/settings location. A common installed executable path is:

C:/Users/<WindowsUser>/AppData/Local/Programs/lnwjud/lnwjud.exe

Always use the path shown by the installed shortcut or Get-Command.

Configure the local desktop application

Add a workspace

1. Start lnwjud (pnpm desktop or the installed app).
2. On Home or Projects, add the project directory path.
3. The selected project is persisted; switching projects restarts MCP automatically.
4. Desktop MCP uses the selected Permission profile; stdio/tunnel MCP uses its separately configured STDIO profile (backward-compatible default: full) and optional Strict Roots.
5. Run Doctor from the sidebar if a dependency is reported missing.

Every file operation resolves the supplied path against a registered workspace, canonicalizes existing parents/targets, rejects traversal and reparse-point escapes, and applies the secret policy after resolution.

Permission profiles

Desktop MCP honors the selected profile for every MCP tool, including local capabilities. The packaged stdio/tunnel runtime keeps full as the backward-compatible default, but accepts safe, balanced, full, or custom through the launcher/environment/Desktop STDIO policy settings; optional Strict Roots can further constrain visible roots. This policy is stored separately from the Desktop MCP profile. Unrestricted mode remains the compatibility default for read/discovery visibility when Strict Roots is not enabled (every fixed drive is a machine root), but it never broadens the host Active Project mutation boundary. The exact recoverable delete_file is the only mutation that can use scoped auto-approval. Destructive Git forms that would rewrite/discard/delete state are blocked when policy cannot prove a safe supported mutation; any allowed opaque mutation still requires explicit chat confirmation and independent host exact-action approval. Disk format, shutdown, and reboot stay hard-blocked.

Optional local capability roots

The local desktop capability layer can receive additional roots through the semicolon-separated environment variable LNWJUD_CAPABILITY_ROOTS:

$env:LNWJUD_CAPABILITY_ROOTS = 'E:/work;E:/projects'

In the default unrestricted mode, all fixed-drive roots are available to local capability read/discovery tools. LNWJUD_CAPABILITY_ROOTS is optional extra configuration; it is not a visibility ignore list. Core file tools still require a registered workspace, and mutation-capable tools still require the exact Active Project and normal confirmation/host-approval boundaries.

Local Streamable HTTP connection

The desktop runtime auto-starts the loopback MCP server after resolving the selected workspace. In the dashboard:

1. Select a registered workspace.
2. Copy the displayed endpoint, normally http://127.0.0.1:18765/mcp.
3. Add it to a compatible local Streamable HTTP MCP client.
4. Use Stop Connection when you intentionally want to stop the listener.
5. Use Start Connection to start it again after a manual stop.

The endpoint binds to 127.0.0.1, validates origin/host, and uses the same application services and permission checks as the dashboard. Do not expose the loopback URL through a generic port forward.

If dom_cdp is available, the dashboard can launch managed Chrome. Browser automation remains loopback-bound and separate from the file guard.

Connect a local Codex client

Local Codex clients can use stdio directly; they do not need Secure MCP Tunnel. Point the entry at the stdio-capable installed executable:

codex mcp add lnwjud -- "$env:LOCALAPPDATA\Programs\lnwjud\lnwjud-mcp-stdio.cmd" --workspace E:\lnwjud
codex mcp list

The stdio launcher is lnwjud-mcp-stdio.cmd shipped next to the desktop app (not the GUI lnwjud.exe). It exposes the full tool catalog, including skills/MCP bridge meta-tools, and uses the bundled private lnwjud-node.exe; no separate Node.js installation is required for an installed release.

The same server can be added in ChatGPT desktop or an IDE extension under Settings → MCP servers → Add server → STDIO. Restart the host after saving. In Codex, /mcp lists active servers.

Example user-scoped or trusted project-scoped config.toml:

[mcp_servers.lnwjud]
command = "C:/Users/<WindowsUser>/AppData/Local/Programs/lnwjud/lnwjud-mcp-stdio.cmd"
args = ["--workspace", "E:/lnwjud"]
startup_timeout_sec = 20
tool_timeout_sec = 3600

Use prompt approval while testing an unfamiliar workspace. No OpenAI API key belongs in this local MCP entry.

Create an OpenAI Secure MCP Tunnel

This is the path that lets ChatGPT web, which cannot read local files or local Codex configuration, call lnwjud.

1. Create or select a Platform tunnel

Open OpenAI Platform tunnel settings. Create a tunnel and record its ID, for example:

tunnel_0123456789abcdef0123456789abcdef

Associate the tunnel with the Platform organization that owns it, the target ChatGPT workspace, and any other Platform organization that will call it. The same tunnel_id is used by every association.

2. Create the correct runtime key

Open OpenAI Platform API keys. Create a runtime API key for tunnel-client and grant Tunnels Read + Use.

Do not use an Admin API key or an unrelated project key (sk-proj-...). Keep the key in a local secret store or environment variable. Never put it in this repository, a YAML profile, a committed .env file, or a public issue/log. If a key is exposed, revoke it and create a replacement.

3. tunnel-client for installed releases

The Windows x64 installer already bundles official OpenAI tunnel-client v0.0.12, so normal installed-release setup requires no separate download or stable external executable path. The Settings path field is only a manual override/troubleshooting control.

For manual CLI troubleshooting or source-development scenarios, define $tc explicitly for the client you intentionally want to test:

$tc = 'C:/path/to/tunnel-client.exe'
& $tc --version

4. Create a Desktop HTTP profile

For installed releases, prefer Settings → OpenAI Secure MCP Tunnel → Configure Tunnel. The desktop starts or reuses its loopback MCP endpoint and repairs a stale profile automatically. Manual initialization is still supported when you need it:

$env:CONTROL_PLANE_API_KEY = '<runtime-key-for-this-session>'
$mcpEndpoint = 'http://127.0.0.1:<port>/mcp' # copy the actual Local MCP endpoint shown by lnwjud

& $tc init --force --sample sample_mcp_remote_no_auth --profile lnwjud --tunnel-id 'tunnel_0123456789abcdef0123456789abcdef' --control-plane-api-key-ref 'env:CONTROL_PLANE_API_KEY' --health-listen-addr '127.0.0.1:0' --mcp-server-url $mcpEndpoint

The Secure Tunnel profile stores a loopback HTTP MCP URL and an env:CONTROL_PLANE_API_KEY secret reference instead of a source-tree command or literal runtime key. Direct local stdio hosts can still use lnwjud-mcp-stdio.cmd, but the OpenAI Secure Tunnel path intentionally goes through the Desktop HTTP runtime so Active Project selection and native approval stay host-owned.

5. Run diagnostics and the tunnel

Prefer the desktop Control Center: save the Runtime API key once under Settings, then click Start Tunnel. The key is stored with Windows DPAPI.

Manual session (still supported):

$env:CONTROL_PLANE_API_KEY = '<runtime-key-for-this-session>'
$env:MCP_CONNECTION_MAX_TTL = '168h0m0s'
& $tc doctor --profile lnwjud --explain
if ($LASTEXITCODE -ne 0) { throw 'tunnel-client doctor failed' }
& $tc run --profile lnwjud --mcp.connection-max-ttl 168h0m0s

Keep lnwjud and tunnel-client running while ChatGPT is using the connector. The tunnel forwards to lnwjud's Desktop loopback HTTP MCP, so Work Log entries, Active Project selection, and native approval remain in the same Desktop runtime.

6. Verify the tunnel target locally

Test-Path -LiteralPath $tc
Get-Content (Join-Path $env:APPDATA 'tunnel-client\lnwjud.yaml') | Select-String 'server_urls:|url:'

The main MCP channel must point to a loopback URL ending in /mcp (for example http://127.0.0.1:<port>/mcp). It must not point to a source checkout, a public/LAN MCP address, or lnwjud-mcp-stdio.cmd for the Secure Tunnel flow.

Advanced: manual tunnel runner at Windows logon

Normal installed-release users should use the Desktop persistent tunnel runtime and its reconnect controls; the bundled tunnel-client requires no separate scheduled task. The example below is only for an intentionally manual runner. It stores the runtime key encrypted with the current Windows user's DPAPI; the key is not written in plain text to the profile or task command line.

Save the key once

$secretDir = Join-Path $env:APPDATA 'tunnel-client'
New-Item -ItemType Directory -Path $secretDir -Force | Out-Null
$secureKey = Read-Host 'Tunnel runtime API key' -AsSecureString
$secureKey | ConvertFrom-SecureString | Set-Content (Join-Path $secretDir 'lnwjud.runtime.secret')

The encrypted value is tied to the same Windows user and machine.

Create a runner script

Save as start-lnwjud-tunnel.ps1:

$ErrorActionPreference = 'Stop'
$tc = 'C:/path/to/tunnel-client.exe' # advanced manual override only
$profile = 'lnwjud'
$secretPath = Join-Path $env:APPDATA 'tunnel-client/lnwjud.runtime.secret'

if (-not (Test-Path $tc)) { throw "Missing tunnel-client: $tc" }
if (-not (Test-Path $secretPath)) { throw "Missing encrypted runtime key: $secretPath" }

$encrypted = Get-Content $secretPath -Raw
$secureKey = ConvertTo-SecureString $encrypted
$keyPointer = [Runtime.InteropServices.Marshal]::SecureStringToBSTR($secureKey)
try {
  $env:CONTROL_PLANE_API_KEY = [Runtime.InteropServices.Marshal]::PtrToStringBSTR($keyPointer)
  & $tc doctor --profile $profile --explain
  if ($LASTEXITCODE -ne 0) { exit $LASTEXITCODE }
  & $tc run --profile $profile
  exit $LASTEXITCODE
}
finally {
  [Runtime.InteropServices.Marshal]::ZeroFreeBSTR($keyPointer)
  Remove-Item Env:CONTROL_PLANE_API_KEY -ErrorAction SilentlyContinue
}

Register the logon task

Run once as the same Windows user who saved the DPAPI secret:

$runner = 'C:/Users/<WindowsUser>/Downloads/tunnel/start-lnwjud-tunnel.ps1'
$userId = "$env:USERDOMAIN/$env:USERNAME"
$argument = '-NoProfile -ExecutionPolicy Bypass -File "' + $runner + '"'
$action = New-ScheduledTaskAction -Execute 'powershell.exe' -Argument $argument
$trigger = New-ScheduledTaskTrigger -AtLogOn -User $userId
$principal = New-ScheduledTaskPrincipal -UserId $userId -LogonType InteractiveToken -RunLevel Limited
Register-ScheduledTask -TaskName 'lnwjud Secure MCP Tunnel' -Action $action -Trigger $trigger -Principal $principal -Force

Check or start it:

Get-ScheduledTask -TaskName 'lnwjud Secure MCP Tunnel'
Start-ScheduledTask -TaskName 'lnwjud Secure MCP Tunnel'

Use Run only when user is logged on and a limited principal unless your organization has a documented service-account design. lnwjud does not need an administrator token for normal workspace operations.

Add the connector in ChatGPT Developer mode

Enable Developer mode

In ChatGPT web:

1. Open Settings.
2. Select Security and login.
3. Turn on Developer mode.

Enterprise/Edu administrators may need to enable this before it appears.

Create the developer app

1. Open ChatGPT Plugins.
2. Select the plus (+) button.
3. Enter a name such as lnwjud and a short description such as Local Windows development workspace gateway.
4. Under Connection, choose Tunnel.
5. Select the tunnel or enter its tunnel_id.
6. Create the connection and review the discovered tools and schemas.

lnwjud does not expose an OAuth login endpoint. Do not invent OAuth URLs or paste the runtime key into the ChatGPT connector form. Tunnel authentication is handled by tunnel-client; ChatGPT selects the OpenAI-hosted tunnel. Choose a no-extra-auth option only when the tunnel form offers it.

Attach it to a new chat

Start a new conversation, open the tools menu, and add the lnwjud connection. A good smoke test is:

Use lnwjud to inspect the available workspace and report only registered workspace IDs and display names. Do not read file contents yet.

Then test a read-only project flow:

For workspace <workspace-id>, show the project snapshot, Git status, and the top-level workspace tree. Do not modify anything.

After changing tool metadata or restarting the tunnel, refresh the connector and continue in the same chat. Start a new chat only if Refresh connector does not clear a stale schema.

Complete MCP tool catalog (223 configurable tools; 217 advertised by default)

This index is generated from the current ToolRegistry, not copied from an older release document. Optional/planned tools still appear in the advertised contract and report their availability/requirements at runtime where applicable.