mcp server
plus-local-agent
ChatGPT-native Windows desktop runtime for permission-controlled local tools and MCP providers.
Set up
Runs on your computer. Pick your agent and operating system.
This project does not publish an install method we can turn into a config. Follow the README instead.
README
synced Oct 29, 2026plus-local-agent
ChatGPT is the interface; PLA is the runtime.
PLA (plus-local-agent) lets ChatGPT work with files, programs, browsers, desktop applications and optional MCP providers on your own Windows PC, within explicitly configured permissions. ChatGPT handles reasoning and tool selection; PLA runs the local tools. The ChatGPT app can be on another device, including your phone, while the Windows PC runs PLA through Secure MCP Tunnel.
Release channel: Stable PLA Desktop v1.0.0 (Windows 10/11 x64). The installer is unsigned and updates are manual. PLA is not an operating-system sandbox or a commercially supported product.
License: PLA-owned source uses Apache-2.0; bundled and optional third-party dependencies retain their own licenses. See third-party notices.
Download PLA Desktop v1.0.0 (Windows x64) · All releases · 简体中文 · Advanced source installation
v1.0.0 release: Stable Desktop installer, explicit executable grants, Apache-2.0 licensing and audited bundled Skill Library. The exact release source passed 991 Python tests and Windows CI, and the owner verified real ChatGPT E2E. See the v1.0.0 release notes for accepted test exclusions and safety boundaries.
PLA Desktop: download, install and connect
For Windows 10/11 x64. The graphical installer bundles PLA Runtime, the minimal Python execution environment and the official Secure MCP Tunnel client. Normal desktop users do not need Git, a source checkout, Python, Node.js or Rust. Those prerequisites belong to source/developer installation below.
1. Download the correct file
-
Go to the PLA Desktop v1.0.0 release or browse all releases for older builds.
-
Expand Assets and download the Windows x64 setup EXE (
PLA.Desktop_1.0.0_x64-setup.exe) together withSHA256SUMS.txt. Do not download “Source code (zip/tar.gz)” as the installer. -
Open PowerShell and run the command below. Compare its hash with the matching installer entry in
SHA256SUMS.txt(change the path if your download directory differs).
Get-FileHash -Algorithm SHA256 -LiteralPath "$env:USERPROFILE\Downloads\PLA.Desktop_1.0.0_x64-setup.exe"
The v1.0.0 installer SHA-256 is ccb99f92eebdcebf111a1c98bb8ca4df7668201c682a94f73dce94b7e8f6fb80. Verify it before opening the installer.
2. Install and open PLA
Double-click the EXE, follow the installer, then launch PLA Desktop from the Start menu. Installation is per-user; administrator elevation is not expected. If Microsoft WebView2 is missing, the bootstrapper needs Internet access. This build is unsigned: Windows may display an “Unknown publisher” / SmartScreen warning. Check the source and SHA-256 before deciding whether to continue; do not disable system-wide protection.
3. Prepare your own Secure MCP Tunnel credentials
Open OpenAI Tunnel management using the intended organization/project, create or select a Tunnel for this PC, and copy its tunnel_... ID. At API Keys, create a dedicated secret runtime API key with appropriate Tunnel access. Tunnel management requires Tunnels Read + Manage; running the client requires Tunnels Read + Use. If these permissions are absent, ask the organization administrator. Never use an organization-admin key, share a key between unrelated computers, or paste it into a public issue.
The packaged desktop already includes tunnel-client.exe: do not download a separate Tunnel client or make a control-plane-api-key.txt file for this desktop workflow. Those steps apply only to the source installation below. See the official Secure MCP Tunnel guide.
4. Configure the PLA Desktop GUI
-
In 首次配置 (First setup), leave the default Runtime/Tunnel health ports unless there is a conflict. Enter the Tunnel ID and Runtime API Key and click 保存连接配置 (Save connection). The key is stored under your Windows account using DPAPI, not in the project repository.
First setup screen (example data; no real Tunnel credentials are shown).
-
Open 工作区 (Workspaces), give one folder a unique Root name (for example
demo) and its full local path (for exampleD:\PLA-Test). Grant Read first; select Write and Controlled execution only if actually needed. Click 添加 root. To change workspace permissions later, stop Runtime first. Do not grant the entireC:\/D:\drive or private credentials directory.Workspace example: grant Read first, and add Write or Execute only when necessary.
-
Return to 总览 (Overview) or 首次配置: click 启动 Runtime (Start Runtime), verify MCP 已就绪, then 运行验证 (Run verification). Next click 连接 Tunnel (Connect Tunnel) and confirm the remote connection status. A local PASS is not yet proof of ChatGPT authorization.
Illustrative connected state; verify your real connection by calling a PLA tool from ChatGPT.
For newly available executable permissions in the v1.0.0 candidate, open Settings → Executable Permissions and grant only a trusted local .exe by its complete absolute path. Disable, re-enable or revoke it from the same list. A newly disabled grant is refused immediately for future calls; already running processes are not terminated. Any authorized process still runs with your Windows account rights and may access files outside the authorized workspace.
5. Connect ChatGPT and test the full path
In ChatGPT's applicable Apps / connectors / MCP settings, add or authorize the connection associated with your Tunnel according to the official guide. The precise menu and eligibility depend on the ChatGPT account. Do not confuse a Platform API key with authorization inside ChatGPT.
With PLA and Tunnel running, ask ChatGPT to list the files in your authorized demo folder. If it succeeds, optionally test creating and reading a harmless file after granting Write. This is the real end-to-end test; a connected-looking status alone is insufficient. You can use ChatGPT on a different computer or phone while PLA continues to run on the Windows host.
Troubleshooting and optional tools
If Runtime is not ready, check 日志诊断 (Logs/Diagnostics) and local port conflicts. If the Tunnel does not connect, check the saved ID/key, organization permissions, network/proxy and then restart the connection. If ChatGPT cannot discover the tools, check its MCP authorization and run the test from a new conversation. For a clean exit, use the PLA system-tray 退出 (Exit) action; closing the main window may leave the app running in the tray.
For browser, Office, Skill Library or other MCP components, open 组件管理 → 本机组件, review installation plans and then enable/verify each component separately. New Desktop builds include a reviewed, SHA-256-checked Skill Library v0.5.0 Wheel; ordinary users need no server source checkout. Personal Skill Sources are never imported or authorized automatically. The Skill Library page supports browsing, enabling/disabling, synchronizing and managing Sources; create/edit/publish Skills through ChatGPT using the existing governed MCP capabilities. The detailed desktop handbook and security boundaries cover additional cases.
Components must be enabled and connected after installation.
Skill Library example data: browse, toggle and synchronize Skills; delegate authoring and publishing to ChatGPT.
What to expect from a Pre-release
- Manual updates: close PLA Desktop before installing a newer release; keep a copy of the previous installer if you need to roll back. The app does not promise automatic rollback.
- Unsigned builds: SHA-256 detects a changed download relative to the published checksum; it does not identify a legally verified software publisher.
- Permission boundaries: workspace roots, allowlists and confirmation policies restrict PLA operations, but they do not provide an operating-system sandbox. Authorized processes run with your Windows account's privileges. Review external MCP providers and Skills before use.
- User-controlled configuration: Tunnel credentials are stored using Windows DPAPI under your account; external Tunnel/account authorization is still required. Upgrading or uninstalling the app normally preserves its separate user data and authorized workspace files.
- Testing: each Pre-release is a development snapshot. Some optional features require separate dependencies and may be unavailable until installed. See the release notes for version-specific evidence and limitations.
Source installation (advanced)
The instructions below are for developers or users who prefer the original source/headless setup. Unlike PLA Desktop, this route requires development prerequisites.
Requirements
- Windows 10/11 x64
- Git for Windows
- Python 3.11
- current Node.js with npm
- Microsoft Edge
- Secure MCP Tunnel credentials for the target machine
- WinGet MCP runtime for the full Windows package-management feature set
- WPS Office for the WPS Office Provider (optional if you do not need Office automation)
Download
Choose an installation directory first. The example below uses a dedicated folder
under the current Windows user profile; change $PlaRoot if you prefer another location.
$PlaRoot = Join-Path $env:USERPROFILE "AI_Tools\plus-local-agent"
New-Item -ItemType Directory -Force -Path (Split-Path $PlaRoot) | Out-Null
git clone https://github.com/ymao31196-blip/plus-local-agent.git $PlaRoot
Set-Location $PlaRoot
For a stable deployment, you may check out the release tag you want before installation. The optional Skill Library Provider requires its independent server package or source checkout; see Skill Library Provider setup. Public PLA configuration never grants local Skill source roots by default.
Install
Run the repository installer:
.\install.ps1
The installer creates the local Python environment, installs reviewed Provider dependencies,
checks prerequisites, and runs validation. The optional Skill Library server is a separate
v0.5.0 package: follow Skill Library setup or supply its
reviewed local source/Wheel with install.ps1 -SkillLibraryPackage <path>. Read and write
access to Skill directories remain disabled until explicitly configured. If customer-specific Tunnel credentials are not yet
configured, a safe local installation may finish as PARTIAL.
Download the Windows x64 Tunnel client from the official
OpenAI Tunnels page (recommended) or
the official tunnel-client releases. Choose
the windows-amd64 ZIP and extract it into a dedicated directory next to PLA. The executable is
named tunnel-client.exe (with a hyphen).
Official setup links:
- Create or manage a Tunnel and copy its Tunnel ID
- Create a secret API key
- Secure MCP Tunnel documentation
- Organization roles and groups, if Tunnel access must be granted by an organization owner or RBAC administrator
Creating or editing a Tunnel requires Tunnels Read + Manage. Running tunnel-client requires
Tunnels Read + Use. Create the secret key under the intended Platform organization/project and
use it as the runtime API key; do not use an organization admin key for PLA.
Create the runtime-key text file in the same directory as tunnel-client.exe:
$TunnelDir = Join-Path (Split-Path $PlaRoot -Parent) "tunnel-client"
$TunnelExe = Join-Path $TunnelDir "tunnel-client.exe"
$TunnelKey = Join-Path $TunnelDir "control-plane-api-key.txt"
# Paste only this machine's runtime API key into Notepad, then save and close it.
if (-not (Test-Path -LiteralPath $TunnelKey)) {
New-Item -ItemType File -Path $TunnelKey | Out-Null
}
notepad.exe $TunnelKey
Test-Path -LiteralPath $TunnelExe
Test-Path -LiteralPath $TunnelKey
The two Test-Path commands should both return True. Do not include quotes, a variable name,
or Bearer in the text file, and do not paste the key into PowerShell command history. Obtain
the Tunnel ID and a runtime API key for this machine from the Tunnels page; do not use an admin
key as the runtime credential.
Then configure the customer Tunnel and start PLA:
.\install.ps1 `
-TunnelId "tunnel_CUSTOMER_ID" `
-TunnelClient $TunnelExe `
-TunnelCredential $TunnelKey `
-PersistEnvironment `
-Start
Machine-specific Tunnel configuration is written to config/tunnel.local.yaml, which is ignored by Git. Do not reuse another machine's Tunnel ID or credential.
For a non-mutating prerequisite check:
.\install.ps1 -ValidateOnly
More deployment details are available in docs/customer_installation.md.
中文安装指南
如果你只想尽快把PLA装起来,可以直接按下面的顺序操作。
1. 准备环境
目标电脑需要:
- Windows 10/11 x64
- Git for Windows
- Python 3.11
- 当前版本的Node.js与npm
- Microsoft Edge
- 目标电脑自己的Secure MCP Tunnel配置
- 如需完整Windows软件管理能力,还需要WinGet MCP runtime
2. 下载PLA
先确定安装目录。下面示例把PLA安装到当前Windows用户目录下的
AI_Tools\plus-local-agent;如果你想安装到其他位置,只需要修改$PlaRoot。
$PlaRoot = Join-Path $env:USERPROFILE "AI_Tools\plus-local-agent"
New-Item -ItemType Directory -Force -Path (Split-Path $PlaRoot) | Out-Null
git clone https://github.com/ymao31196-blip/plus-local-agent.git $PlaRoot
Set-Location $PlaRoot
这样无论你从哪个PowerShell目录开始执行,PLA都会被clone到明确的目标位置,而不是落在当前目录。
如果你希望使用稳定版本,可以在安装前切换到对应的release tag。
3. 安装本地运行环境
执行:
.\install.ps1
安装器会自动创建本地Python环境、安装经过审查的Provider依赖、检查运行条件并进行验证。
如果此时还没有配置这台电脑自己的Secure MCP Tunnel,安装结果可能显示为PARTIAL。 这通常表示本地PLA已经安装完成,只差Tunnel等外部连接条件,并不等于安装失败。
4. 配置Secure MCP Tunnel并启动
先打开下面的官方页面:
- 创建或管理Tunnel并复制Tunnel ID
- 创建Secret API Key
- Secure MCP Tunnel官方文档
- 如果页面提示权限不足,由组织Owner或RBAC管理员在Roles 和Groups中授权
创建或编辑Tunnel需要Tunnels Read + Manage权限;运行tunnel-client需要
Tunnels Read + Use权限。请先选对Platform组织/项目,再创建这台电脑专用的Secret Key,
把它作为runtime API key使用;PLA不应使用Organization Admin Key。
然后按以下步骤准备文件:
- 在OpenAI官方的Tunnels管理页面
创建或选择这台电脑要使用的Tunnel,并复制以
tunnel_开头的Tunnel ID。 再从API Keys页面创建Secret Key;Secret Key通常只在 创建时完整显示一次,请立即安全保存。 如果页面暂时不能直接下载,也可以从OpenAI官方的 tunnel-client Releases下载。 - 选择Windows x64对应的
windows-amd64ZIP。不要下载Source code压缩包。 - 把ZIP解压到PLA目录旁边的独立
tunnel-client目录。程序的实际文件名是tunnel-client.exe(中间是连字符-,不是下划线_)。 - 在
tunnel-client.exe同一目录创建control-plane-api-key.txt,文件中只放runtime API key 本身,不要加引号、变量名或Bearer前缀。
下面的命令会确定两个文件的路径,并用记事本创建key文件:
$TunnelDir = Join-Path (Split-Path $PlaRoot -Parent) "tunnel-client"
$TunnelExe = Join-Path $TunnelDir "tunnel-client.exe"
$TunnelKey = Join-Path $TunnelDir "control-plane-api-key.txt"
# 在记事本中粘贴这台电脑专用的runtime API key,然后保存并关闭。
# 不要把真实key直接写进PowerShell命令,以免进入命令历史。
if (-not (Test-Path -LiteralPath $TunnelKey)) {
New-Item -ItemType File -Path $TunnelKey | Out-Null
}
notepad.exe $TunnelKey
Test-Path -LiteralPath $TunnelExe
Test-Path -LiteralPath $TunnelKey
最后两条命令都应返回True。目录结构应类似:
AI_Tools\
|-- plus-local-agent\
| `-- install.ps1
`-- tunnel-client\
|-- tunnel-client.exe
`-- control-plane-api-key.txt
准备好这三个值后执行:
.\install.ps1 `
-TunnelId "tunnel_CUSTOMER_ID" `
-TunnelClient $TunnelExe `
-TunnelCredential $TunnelKey `
-PersistEnvironment `
-Start
PLA会把本机Tunnel配置写入config/tunnel.local.yaml。这个文件不会进入Git。 不要复制或复用其他电脑、其他用户的Tunnel ID或credential,也不要把key文件放进PLA仓库或提交到Git。
5. 只检查环境,不执行安装
如果想先确认电脑是否满足要求:
.\install.ps1 -ValidateOnly
6. 安装完成后的常用命令
启动PLA:
.\start_all.ps1
停止PLA:
.\stop_all.ps1
仅在修改源码后重启PLA HTTP:
.\restart_pla.ps1
PLA运行并连接Secure MCP Tunnel后,你可以继续直接使用ChatGPT作为界面。 ChatGPT可以来自同一台电脑,也可以来自手机、网页端或另一台设备;真正的本地执行仍发生在运行PLA的Windows电脑上。
更完整的部署说明见docs/customer_installation.md。
Core capabilities
| Area | What PLA provides |
|---|---|
| Local execution | Controlled file, process, Python and local program execution, including governed WSL access plus allow-listed latexmk/xelatex, and structured PowerShell diagnostics for processes, services, TCP/UDP endpoints, adapters, routing, IP-interface metrics/DHCP/MTU, IP/DNS configuration, bounded System/Application event logs, scheduled-task state, file signatures and workspace ACLs |
| Browser | Independent browser runtime with persistent PLA-managed profiles, reusable login sessions, and semantic accessibility/ref-based interaction |
| Computer Use | Windows UI Automation with restricted selector-targeted input fallbacks |
| Documents | WPS Office automation plus reviewed PDF and Markdown conversion capabilities; the standalone DOCX MCP component has been removed |
| Windows management | Observation, WinGet integration and narrowly controlled application operations |
| Artifacts | Structured artifact export, metadata, chunking and provenance checks |
| Providers | Manifest-backed MCP providers with isolated environments and hot reload |
| Transactions | Durable multi-step actions with checkpoints, confirmation and recovery state |
| Events and policy | Event, Observer and Gate planes for audit and policy enforcement |
| Workspaces | Deployment-local authorized roots separated from PLA source |
| Git | Expected-HEAD, explicit-path staging/removal, commits, tags and controlled pushes |
| Runtime lifecycle | Independent lifecycle broker for bounded HTTP restart and health checks |
The Browser Provider uses a PLA-managed persistent profile. After you sign in to a site inside that profile, later browser tasks can reuse the stored login state instead of starting from a fresh browser session each time. The PLA browser profile is separate from your normal Edge profile and does not directly inherit an already-running Edge session.
System write operations use a separate windows.* capability boundary instead of expanding the generic PowerShell tool. windows.flush_dns_cache requires explicit INVOKE confirmation. windows.service_control_preflight is read-only and reports service state, dependent-service state, policy authorization, broker readiness and concrete blockers before any elevation request is created. windows.service_control additionally requires a transaction context and a deployment-local rule in config/windows_actions.local.json for the exact service and operation, so authorizing restart does not automatically authorize stop. Service actions are rechecked immediately before queueing and again by the Interactive Elevation Broker before UAC; disabled or unstable services, services that cannot stop, and stop/restart operations with active dependent services are rejected. The caller cannot supply an executable or command line. External-pending actions can declare a fixed read-only completion verifier. The Transaction Envelope validates that verifier immediately when the pending result is received, rejecting contracts that point to write, confirmation-gated, or transaction-gated capabilities. It then persists the accepted completion contract, prevents ordinary succeeded checkpoints from bypassing it, and exposes core.transaction_complete_external, which can only invoke the recorded verifier and marks the step successful after the verifier reports completed. Completion-gated running actions survive a PLA runtime restart as resumable running steps with a new transaction revision; ordinary running steps without a trusted completion contract are still recovered as interrupted and blocked. Windows service control and the elevated software migration flows use this Completion Gate. windows.elevation_broker_restart is a separate confirmed lifecycle action that refuses to restart a busy Broker and verifies process identity before replacement. Copy config/windows_actions.example.json when you intentionally want to add a service rule on one machine. The local policy file is ignored by Git and protected from normal PLA file access.
Use ChatGPT anywhere
ChatGPT Agent Brain
|
| MCP through Secure MCP Tunnel
v
Stable Capability Surface
capability_search / capability_describe / capability_invoke
|
v
PLA on the target Windows PC
+-- Capability Registry / Broker
+-- Semantic / Execution Policy
+-- Production Execution Runner
+-- Persistent Session Runtime
+-- Browser / Computer providers
+-- Artifact Plane
+-- Durable Task / Transaction Store
+-- Event / Observer / Gate Plane
+-- Runtime Lifecycle Broker
+-- Interactive Elevation Broker
+-- External MCP providers
PLA does not contain a second autonomous planner and no longer carries an MCP Sampling execution path. Providers expose reviewed capabilities; ChatGPT remains the Agent Brain and decides how to combine them into multi-step work.
Stable capability surface
External Provider tool catalogs are not copied wholesale into ChatGPT's MCP schema. PLA keeps a small hot-path surface for common local work and routes specialized or low-frequency operations through the Capability Registry.
The v2.0.0 runtime exposes 23 top-level MCP tools. These cover the capability router itself plus high-frequency file, process, artifact-export, task, Git status/diff, and recovery/diagnostic paths. The broader runtime is discovered on demand through:
capability_search
capability_describe
capability_invoke
At the v2.0.0 release point, the live registry contains 412 dynamic capabilities. ChatGPT searches that registry, inspects the selected capability, and invokes only what is needed for the current step instead of receiving every Provider tool schema up front.
Provider manifests define tool allowlists, risk levels, confirmation requirements, transaction requirements, artifact policy, runtime constraints, and dependency setup.
Python Providers run in isolated Provider environments. Reviewed Node and native executable Providers can also be integrated without opening arbitrary shell execution. Source-backed Node Providers may additionally pin a GitHub repository to an exact commit, apply repository-owned compatibility patches, and build through the fixed Provider setup path; runtime execution still uses the ordinary manifest and capability-policy boundary.
Provider management
Manifest-backed Providers can be inspected and updated through the built-in runtime capabilities:
runtime.provider_status
runtime.provider_setup
runtime.provider_rescan
runtime.provider_reload
runtime.provider_enable
runtime.provider_disable
Provider setup installs only reviewed, pinned dependency specifications through repository-owned entrypoints. Runtime changes do not bypass manifest validation, tool allowlists, confirmation policy, transaction policy, or execution boundaries.
Mutating Provider operations require explicit INVOKE confirmation.
Durable transactions and confirmation
High-risk multi-step work can use durable transaction capabilities:
core.transaction_create
core.transaction_get
core.transaction_checkpoint
core.transaction_finalize
core.transaction_invoke
Transactions persist plan state, optimistic revisions, verification checkpoints, rollback state, and interrupted-step information.
A capability marked requires_transaction cannot be called directly. A capability marked requires_confirmation additionally requires explicit INVOKE approval.
Event, Observer and Gate planes
PLA records bounded execution events such as:
capability.gate_denied
capability.before_invoke
capability.succeeded
capability.failed
Event records use bounded metadata and hashes instead of storing raw capability arguments or raw results by default.
Observer Hooks can react to persisted events without changing the selected capability's result. Gate Hooks run before execution and can allow or deny a capability under a deny-overrides policy. Gate failures fail closed.
Read-only inspection includes:
core.event_query
core.hook_status
core.hook_invocation_query
core.gate_status
core.gate_decision_query
External Observer plugins are supported through reviewed manifests and isolated runtimes. Third-party code does not receive authority to silently expand PLA's execution boundary.
Runtime lifecycle
PLA separates the HTTP Control Plane from its default generic one-shot Execution Plane. Normal
run_process execution uses an authenticated out-of-process Execution Runner; persistent process
sessions and structured PowerShell keep their existing specialized paths. Each one-shot request has
an exact execution_request_id, allowing the Control Plane to reconnect to retained Runner results
after an HTTP restart without replaying the command.
The production Runner validates its own process identity, protocol version, workspace/root policy, program allowlist, environment overrides, and semantic execution policy before spawning a child. Task cancellation is forwarded by exact request ID and can terminate only the child tree owned by that Runner request; PLA does not expose an arbitrary PID-kill surface.
PLA also uses an independent Runtime Lifecycle Broker for controlled HTTP restart:
runtime.lifecycle_status
runtime.restart_http
runtime.restart_status
runtime.execution_runner_status
runtime.execution_runner_result
runtime.restart_http requires explicit INVOKE. The broker validates the expected PLA HTTP
process before restart, while the Secure MCP Tunnel and production Execution Runner remain separate
from the HTTP process. Normal start_all.ps1 startup ensures the Runner; stop_all.ps1 requests a
graceful Runner shutdown.
A dropped connection is not treated as proof of success; restart status, Runner identity, and retained execution state are checked explicitly.
Interactive elevation
PLA normally runs without administrator privileges. UAC-sensitive operations are separated into an Interactive Elevation Broker in the signed-in Windows session.
The broker does not provide arbitrary runas. It accepts only reviewed request shapes, such as narrowly defined uninstall or WinGet installation operations. Windows UAC remains the final local user boundary.
Runtime workspace registry
PLA separates product source from customer workspace authorization.
Built-in roots:
- pla: PLA source and development root
- workspace: repository-local default runtime workspace
Additional customer roots are stored in the Git-ignored:
config/workspaces.local.yaml
They can be inspected and managed through:
core.workspace_roots_get
core.workspace_root_upsert
core.workspace_root_remove
Workspace mutations require explicit INVOKE and optimistic config-SHA matching. Customer roots cannot overlap the PLA source tree.
Current reviewed Providers
The production Provider set includes capabilities for:
- Browser automation
- Windows Computer Use
- Markdown/document conversion
- PDF processing
- WinGet package discovery and reviewed installation
- Windows observation and narrowly controlled application management
- Software migration workflows
- WPS Office automation through the reviewed
lc2panda/wps-skillsMCP provider, including documents, spreadsheets, presentations and the broader Office tool surface - Office补强 (
office-enhancement) for artifact-tool editable PPT overlays, ZIP/OpenXML surgical merges, Microsoft PowerPoint COM rendering/overflow inspection, and PyMuPDF figure extraction - Skill Library access for advisory reusable
SKILL.mdexperience, with cache-first search/read and Git-backed refresh
The WPS Office Provider is installed as a source-backed Node Provider pinned to a reviewed upstream
commit. PLA applies its tracked Windows COM compatibility patch before build, then exposes the
upstream MCP tools through the same capability registry. Common spreadsheet reads are classified as
read, ordinary writes/formatting/saves as write_local, while destructive worksheet/row/column
operations and raw method execution remain confirmation-gated. WPS remains the primary Office
automation surface for ordinary document, spreadsheet and presentation editing. The standalone
DOCX MCP component has been removed. Windows use requires WPS Office and Node.js 18+.
Office补强
office-enhancement is the specialist path for presentation work where ordinary Office editing is
not enough. It keeps four complementary techniques behind one reviewed Provider:
structured artifact-tool overlay
↓
zipfile + lxml OOXML merge
↓
Microsoft PowerPoint COM render / inspect
↓
PyMuPDF PDF image extraction / region rendering
The artifact-tool adapter accepts structured shapes, text, images and connectors; it does not execute
caller-supplied JavaScript. It discovers the installed Codex primary-runtime
@oai/artifact-tool package at invocation time and resolves the package's declared export entry.
The package is therefore an optional local runtime dependency rather than a vendored PLA dependency.
OOXML merge operations copy only relationships actually referenced by the overlay elements, preserve the target deck's existing package/master/layout structure, remap relationship/shape IDs, and copy referenced media under new package names. PowerPoint COM is used for actual Microsoft PowerPoint rendering and text-geometry inspection, including likely overflow checks. PyMuPDF handles embedded image extraction and page/region rendering so vector charts can also be recovered as PNG.
Use WPS for routine Office work. Use Office补强 for surgical PPTX editing, editable technical diagrams, format-preserving merge work, real PowerPoint QA, and PDF figure extraction.
The Skill Library Provider is intentionally lighter-weight. Skills are advisory reusable experience used to reduce recurring mistakes, preserve stable workflows, and surface easy-to-forget conventions. They do not override current user instructions, task facts, or ChatGPT's judgment.
The exact loaded Provider set can be inspected at runtime with runtime.provider_status. The v2.0.0
release point has ten active external Providers; WPS exposes 250 capabilities and Skill Library
exposes four.
Software migration
PLA includes a reviewed software-migration flow designed around verification rather than blind uninstall/reinstall:
assess
-> prepare snapshot
-> verify backup / preconditions
-> transaction-gated uninstall
-> Interactive Elevation Broker + UAC
-> transaction-gated install to target
-> verify registered install location
-> verify user data
-> commit or rollback
The migration layer is intentionally narrower than arbitrary package-management or shell access.
Controlled Git writes
Git mutations use explicit repository state and file identity checks.
git_stage requires an expected HEAD and SHA-256 for each selected file. git_commit commits only the exact staged path set. Release-oriented tag and push operations also require exact branch/HEAD matching and explicit confirmation; force push is unavailable.
Generic process execution does not bypass this boundary for the PLA source repository. If ChatGPT
tries to run git through run_process with root="pla", PLA returns a structured
specialized_capability_required decision with the governed Git tools/capabilities that should
be considered next. PLA does not automatically substitute or invoke the suggested action.
This lets ChatGPT work on real repositories without turning Git into an unrestricted shell escape.
Capability steering
PLA keeps deterministic routing rules for generic execution paths that overlap a governed specialized capability. A steering rule never invokes the suggested replacement. It returns a structured decision with the matched domain, routing mode, attempted route and ordered capability suggestions, leaving the next choice to ChatGPT.
Current enforced routes include PLA-source Git through run_process and Windows service state changes
through run_powershell. The read-only dynamic capability core.capability_route can also evaluate
a proposed capability_invoke before execution. Enforced overlaps return specialized_required;
advisory overlaps return specialized_preferred; unrelated routes return generic_allowed.
The first advisory rule covers explicit browser targets sent through the Computer Provider. When a
Computer capability such as inspect, click, type, press, wait, search or screenshot names Edge,
Chrome, Chromium or Firefox in its app argument, PLA prefers the corresponding browser.*
capability while keeping Computer Use available as a fallback. PLA does not infer browser identity
from an opaque HWND alone.
Routing is invoked through the existing capability_invoke surface, so the steering layer can grow
without adding another fixed top-level MCP tool. Read-only Get-Service, GitHub CLI gh, and
customer-workspace Git are not redirected by the enforced rules.
External providers can also declare routing metadata in their manifest. Capability descriptors carry
routing_authority plus preferred_over, fallback_for, or supersedes relations, optionally
guarded by argument conditions. External manifests are limited to recommendation or preferred
authority; enforced remains reserved for PLA built-in policy. Routing reads the live Capability
Registry on every query, so provider add/change/enable/disable/remove operations take effect after the
normal hot-rescan without restarting the routing layer.
The read-only dynamic capability core.routing_audit inspects the complete Capability Registry and
the maintained Routing Catalog. It checks that catalog rules still reference real capabilities, then
surfaces conservative cross-provider overlap candidates using action aliases, risk compatibility,
shared tags and explicit provider relationships. Candidates are review hints only: the audit never
creates, changes or invokes a routing rule.
Audit candidates have three review states. covered means an active routing rule already handles the
overlap. reviewed_parallel means the overlap was examined and intentionally kept as separate
capability surfaces because the responsibilities differ. Only uncovered candidates still need
routing review. Broad search-like actions are ignored unless an explicit provider relationship exists,
which prevents unrelated UI, process and package searches from being treated as duplicates.
Start and stop
Start PLA and the required local services:
.\start_all.ps1
Stop them:
.\stop_all.ps1
Restart only the PLA HTTP runtime after source changes:
.\restart_pla.ps1
Validation
Run the full regression suite:
python -m pytest -q
Runtime state, Provider environments, credentials, local Tunnel configuration, logs, IDE state, and customer workspace outputs are excluded from Git.
Source layout rules and module responsibility boundaries are documented in docs/source_layout.md. Python implementation modules no longer live at the repository root, low-level runtime start/stop helpers live under scripts/, and tests/test_source_layout.py guards the layout against regression.
The final v2.0.0 Runtime / Execution Plane regression baseline is:
762 passed
Design principles
- ChatGPT stays the Agent Brain. PLA does not add a competing autonomous planner.
- ChatGPT stays the UI. PLA focuses on execution and safety rather than building another chat app.
- Capabilities are reviewed and bounded. Arbitrary shell execution is not the default integration model. PowerShell remains a fixed cmdlet/parameter allowlist; diagnostic output is projected to bounded structured data, and task cancellation only terminates runtime-owned process trees.
- Local state stays local. Credentials, customer workspace roots and deployment configuration are not product source.
- High-risk actions are explicit. Confirmation, transactions, UAC and Git preconditions remain separate safety layers.
- Providers are extensible without flattening security. New MCP capabilities still pass through the same runtime policy boundary.
- Keep the top-level tool surface small. High-frequency recovery paths stay directly visible; specialized, governance and provider-specific operations are discovered through the Capability Registry.
- Separate Control Plane from Execution Plane. Generic one-shot work runs in the independent production Runner; HTTP restart must not replay already accepted commands. Persistent sessions remain on their specialized runtime until a real need justifies migration.
- Do not pretend wrapper policy is an OS sandbox. The current filesystem boundary remains PLA wrapper policy and execution metadata records
sandbox_mode=none. A real OS sandbox is a separate future capability, not a documentation claim.