Puter MCP Connector 实战指南用 Cloudflare Workers 把个人 Puter 账号接入任意 MCP 客户端【免费下载链接】puter The Internet Computer! Free, Open-Source, and Self-Hostable.项目地址: https://gitcode.com/GitHub_Trending/pu/puterPuter MCP Connectorputer-mcp是 Puter 仓库中位于 src/mcp-connector 的一个独立子项目它以 Cloudflare Workers 为运行载体把 Puter 账号的文件系统、静态网站托管、服务端 Workers、KV 存储、应用注册能力以 MCPModel Context Protocol工具的形式暴露给 Claude、Cursor 等任意 MCP 客户端。读完本文你将掌握它的架构原理如何在 Worker 中「零凭据」地以每个调用者身份运行真实 puter.js、全部 45 个工具的参数语义、本地开发/生产部署/自托管接入的完整流程以及 OAuth 免拷贝 Token 接入与 curl 冒烟测试方法。概述无共享凭据的「个人 Puter 网关」MCPModel Context Protocol是一种让 AI 客户端调用外部工具的标准协议。Puter MCP Connector 的特殊之处在于两条设计承诺Worker 本身不保存任何凭据。它不像常见的 MCP 服务器那样用一把「服务账号」密钥代理所有用户而是让每个请求以调用者本人的身份运行认证方式对开发者透明。请求既可以通过Authorization: Bearer token头携带个人 Token也可以通过 Worker 自托管的 OAuth「Sign in with Puter」流程获得 Token详见认证。MCP 客户端 (Claude / Cursor / ...) │ JSON-RPC 2.0 over Streamable HTTPPOST / 或 /mcp ▼ Cloudflare Workerputer-mcp无自有凭据 │ 依据请求头构建调用者本人的 puter.js 实例 ▼ Puter APIapi.puter.com 或自托管端点这意味着部署一次之后任何持有效 Puter 账号的人都能把 MCP 客户端指向这个 Worker URL 使用自己的账号资源——文件、网站、Worker、KV、应用互不串扰。工作原理一个「没有 me 的 Worker」分叉在 How it works 一节中README 明确说明这是src/worker—— Puter 将 puter.js 移植到 Cloudflare Worker 运行时的实现 —— 的一个分叉仅有两处改动去掉了me.puter原版 Worker 会用globalThis.puter_auth创建一个属于 Worker 自己的 puter 实例这个分叉删掉了它于是服务器不持有任何自身凭据。user.puter改为从Authorization头构建按请求创建的 puter 实例由Authorization: Bearer token生成而不是原版的puter-auth头。这两处改动集中在 src/s2w-router.js 的route()中路由收到请求后先用getBearerToken()从authorization头解析 Bearer Token若存在则调用init_puter_portable(token, globalThis.puter_endpoint || https://api.puter.com, userPuter)生成实例并挂到event.requestor.puter即event.user.puter未携带 Token 时则跳过——后续由 MCP 层以 401 应答。之所以能做到「每个请求各用各的 puter.js」关键在于 template/puter-portable.template 中定义的init_puter_portable当类型为userPuter时它会把全局对象快照进一个goodContext然后在with (goodContext)语句中内联执行 puter.js。这样每个请求都运行在隔离的with上下文里并发请求之间不会共享全局可变状态Token、缓存等。模板还通过trimPerRequestOverhead()削减了每请求开销由于单次工具调用并非「打开一次应用」它会屏蔽request_rao_记录应用打开的POST /rao与cacheWhoami_GET /whoami缓存并断开 FileSystem 模块只为缓存失效而建立的 socket。一个值得注意的实现细节是整个模板刻意不做 bundler 转译因为wrangler.toml里设置了no_bundle true——现代转译会输出严格模式 ESM而严格模式禁止with语句Strict mode code may not include a with statement上传原样拼接的脚本才能让它作为 sloppy-mode service worker 运行。MCP 层手写的 JSON-RPC 调度器MCP 传输层采用Streamable HTTP单一端点接受 JSON-RPC 2.0 的POST请求单个消息或批量数组服务器完全无状态。调度器实现在 src/mcp.js被注册到分叉路由上形成以下路由表方法路径用途POST/、/mcpMCP JSON-RPC 端点单消息或 batchGET/、/mcp、/health发现 / 健康检查公开可缓存在 src/mcp.js 的handleMessage()中可以看到协议兼容细节服务器声明当前协议版本为2025-06-18同时接受客户端协商2025-03-26、2024-11-05SUPPORTED_PROTOCOL_VERSIONS对notifications/*类消息返回空响应HTTP 202initialize响应中的instructions会明确告知客户端如何认证、工具分组以及「写 Worker 代码前先调用puter_docs_get读取Workers/router」。批量数组使用Promise.all并行处理。未认证访问的路径也经过精心设计当请求缺少 Token 时mcpPost返回401并带WWW-Authenticate: Bearer resource_metadataorigin/.well-known/oauth-protected-resource——这正是 Claude Code 等 MCP 客户端识别「需要走 OAuth」的信号。同时凡是返回用户数据的响应都强制Cache-Control: no-store防止 Worker 前面的任何边缘缓存把某一用户的 MCP 结果泄漏给其他人src/mcp.js只有公开的发现信息端点显式标注Cache-Control: public, max-age300以便 CDN 缓存。OAuth 相关响应同样带no-store, no-cache, must-revalidate见 src/oauth.js避免缓存层重放某位用户的/authorize重定向。文件地图路径角色src/s2w-router.js分叉路由从 Bearer Token 构建event.user.puter无me.puter处理 CORS 与 JSON 错误响应src/index.js入口initS2w()后注册 MCP 与 OAuth 路由src/mcp.jsMCP JSON-RPC 调度未认证返回 401 WWW-Authenticatesrc/oauth.jsOAuth 桥发现端点、/register、/authorize→authme、/oauth/callback、/tokensrc/tools.js全部工具定义与处理器调用真实的puter.fs.*/puter.hosting.*/puter.workers.*/puter.apps.*src/tools.upload.test.js签名上传工具的真实往返集成测试template/puter-portable.templatePreamble 模板定义init_puter_portable内联 puter.jswrangler.tomlWorkers 配置入口、no_bundle、[vars]、OAuth 密钥说明工具总览七个能力域工具定义与其 JSON Schema 输入参数全部集中在 src/tools.js 的TOOLS数组里每个条目包含name、description、inputSchema通过tools/list暴露给客户端与handler(puter, args)。TOOL_MAP负责按名称查表listTools()会剥离内部字段后生成tools/list载荷。Account身份与路径锚点工具说明whoami获取已认证用户信息username、uuid、home directory。等价于puter.auth.getUser()whoami是绝大多数会话的第一步因为所有路径都必须位于主目录之下。它的处理器会把返回结果补上home_directory: /username字段src/tools.js让 Agent 据此拼接合法绝对路径。Filesystem读写与目录操作工具说明fs_read_file读文件UTF-8 或 base64可选 byte offset/length 窗口fs_statstat 文件或目录大小、类型、时间戳、uidfs_write_file以内联内容创建/覆盖文件UTF-8 或 base64fs_start_upload获取预签名 URL带外上传本地文件fs_complete_upload完成一次fs_start_upload发起的上传fs_abort_upload丢弃一次上传而不创建文件fs_mkdir创建目录可选自动创建缺失父目录fs_delete删除文件或目录默认递归fs_readdir列出目录条目fs_copy复制文件或目录到其他位置fs_move移动文件或目录兼作重命名fs_rename原地重命名文件或目录从 src/tools.js 的 inputSchema 中可以提取这些有实践价值的默认值与边界fs_read_fileencoding枚举utf8/base64默认utf8offset字节起始默认 0、length返回字节数默认到文件尾。读取窗口不是在请求里下发而是在服务器端切片——puter.fs.read会把 offset/byte_count 当查询参数传给后端而后端只认Range头透传会静默返回整个文件因此处理器先全量读取再在decodeReadResult()中做Uint8Array.subarray切片并在_meta.total_bytes中报告总长以便分页。fs_statreturn_size默认true对目录也要计算大小。fs_write_file必填pathcontentoverwrite默认true、create_missing_parents默认false、dedupe_name默认false。base64 内容会解码成Blob再写入。fs_mkdircreate_missing_parents默认开启! false即视为开启。fs_deleterecursive默认truepath既可以是字符串也可以是路径数组。fs_copy/fs_move当目标是一个已存在目录时条目会被「复制/移入」该目录并沿用原名否则目标被当作新的完整路径。new_name可显式改名dedupe_name开启时冲突自动改名为file (1).txt。复制/移动的处理器会剥掉 API 返回的{ copied: entry }/{ moved: entry }信封让所有fs_*工具返回一致的单条目形状。fs_move的一个陷阱后端/move要求目标父目录必须已存在所以create_missing_parents开启时ensureMoveDestination()会先按与puter.fs.move相同的规则确定目标目录必要时预建src/tools.js该目录若后续移动失败会被遗留。fs_renamenew_name是裸文件名而非路径且只能在同一父目录内重命名。上传本地大文件三步签名上传协议fs_write_file的内容是内联传输的——磁盘上的文件必须先经 Agent 上下文 base64 编码才能到达服务器大文件会非常慢且超过客户端消息大小上限后就彻底不可行。fs_start_upload完全绕开这一点它返回一个预签名存储 URL字节直接从持有文件的机器流向存储既不经由此服务器也不经过对话上下文。fs_start_upload({ path: ~/uploads/build.zip, size: 48210433, local_path: ./build.zip }) - { upload_id, url, upload_command, expires_at, ... } # 运行返回的 upload_command curl -sS --fail-with-body -X PUT -H Content-Type: application/zip \ --upload-file ./build.zip https://... fs_complete_upload({ upload_id }) - 新建的文件条目在fs_complete_upload成功之前文件在 Puter 中并不存在上传失败时应调用fs_abort_upload释放挂起的会话。签名本身带来两条硬约束size必须是文件的精确字节数用wc -c file获取原样传入PUT 必须携带签名时一致的Content-Type——存储端对两者任一不匹配都会拒绝。服务器生成的upload_command已经替你把这两者都写对用shellQuote安全地单引号包裹。Content-Type 会按目标扩展名猜测映射表覆盖文本、压缩包、图片、音视频等常用类型src/tools.js猜不到时回退为application/octet-stream也可以显式传content_type覆盖。expires_in签名 URL 有效期秒数由后端钳制在 60~3600默认 900超期未完成则作废。需要特别说明的是超过服务器单次 PUT 上限的文件需要走多段 multipart 的分段编排而这套工具并未实现。fs_start_upload会检测到后端返回的uploadMode不是single或没有url的情况自动先调用/fs/abortWrite释放该会话再抛出 too large for a single-shot signed upload 的明确错误src/tools.js。这段流程由 src/tools.upload.test.js 做了真实往返集成测试验证mint 一个 URL → 像 shell 命令那样 PUT 字节 → finalize → 回读文件比对内容测试同时断言upload_command里携带了签名的Content-Type与正确的--upload-file路径还覆盖了「abort 后 complete 不会复活文件」「超过单次上限被拒绝」等边界。Hosting把目录发布成静态网站在 Puter 中「托管一个网站」意味着创建一个托管子域名站点访问地址为https://subdomain.puter.site后端由你 Puter 文件系统中的一个目录支撑。工具说明hosting_list列出调用者已发布的网站托管子域名hosting_get按子域名获取网站hosting_create在子域名上发布网站可选指向某个root_dirhosting_update把网站重新指向另一个root_dirhosting_delete取消发布网站删除子域名不删文件按 src/tools.js 的说明hosting_create的子域名标签要求为小写字母、数字、连字符最长 64 字符省略root_dir可以只保留子域名、稍后用hosting_update再挂目录。一个 Agent 发布网站的典型链路是fs_mkdir建目录 →fs_write_file写入index.html等文件 →hosting_create将root_dir指向该目录。Workers从文件部署的无服务器函数Puter Workers 是从你文件系统中的某个 JS 文件部署的无服务器函数。Worker 文件在全局router对象上定义处理器router.get/router.post/ …并且拥有完整的 puter.js SDK以puter全局可用——它们的设计目标就是配合 puter.js 与 Puter 认证使用。更新一个 Worker 只需把新代码写回它关联的文件即可没有单独的 update 调用传播约需 5–30 秒。工具说明workers_create从 JS 文件部署 Worker返回其公开 URLworkers_list列出调用者已部署的 Workerworkers_get按名称获取 Worker名称、URL、源文件workers_exec以已认证用户身份通过 HTTP 调用 Workerworkers_delete取消部署 Worker保留其源文件在 src/tools.js 中可以看到workers_create要求账号邮箱已验证worker_name会自动转小写源文件最大 10MBworkers_exec支持 GET/POST/PUT/DELETE/PATCH/OPTIONS/HEAD并且会带着调用者的 Puter 认证头去请求——正因如此它有一个硬性安全校验assertWorkerUrl()目标必须是https://且主机名以.puter.work结尾否则直接拒绝src/tools.js从根上杜绝了把用户 Token 误发给任意第三方的可能。Apps把网站/Worker 注册成可启动应用Puterapp是你账号中的一个已注册应用它会出现在你的 Puter 应用列表里可以在 Puter 桌面 UI 中启动获批后还能上架 marketplace。app 的核心是index_url——运行时 Puter 加载的地址通常是用hosting_create发布的站点或一个 Worker URL。典型流程是fs_write_file写入文件 →hosting_create发布并取得 URL →apps_create把index_url指向该 URL。工具说明apps_list列出调用者拥有/可编辑的应用名称、URL、图标、聚合使用统计apps_get按名称获取应用传stats_period可看窗口内详细的打开/用户数apps_create注册新应用必填name和index_urlapps_update按名称更新应用只改传入字段new_name用于改名apps_delete删除应用index_url指向的站点/Worker 保留apps_check_name创建前检查应用名是否可用apps_create的可选参数相当丰富见 src/tools.jstitle缺省用 name、description最长 7000 字符、icon只接受 base64 或data:image/type;base64,...URL不接受任意 http(s) 图标 URL、maximize_on_start、background、filetype_associations如[.txt, .md, image/png]、metadata、dedupe_name。apps_get的stats_period枚举包括today/yesterday/7d/30d/this_week/last_week/this_month/last_month/this_year/last_year/12m/all。KVJSON 值的键值存储Puter 的 KV 存储在每个用户账号内按 app 命名空间隔离。此连接器用用户 Token认证因此这些工具默认读写用户自己的命名空间每个工具都可选传app_uuid来指向某个单一应用的存储例如某个已部署 Worker 运行时所在的sandbox-workerapp。值以 JSON 存储接受「点路径」profile.bio的工具按路径深入到已存对象内部空路径表示值本身。工具说明kv_get读一个键缺失键读作nullkv_set创建/覆盖一个键可选带过期时间戳kv_del删除一个键kv_list按 pattern 列出键或键值对支持分页kv_incr/kv_decr增减一个数字或按点路径增减对象内数字kv_add向已存值累加数字求和、数组追加kv_update设置已存对象内部特定点路径kv_remove从已存对象中移除点路径kv_expire/kv_expire_at让键在 N 秒后 / 在指定时间戳过期flush被刻意不暴露——「一条调用清空整个存储」不是 Agent 应该具备的能力。实现细节src/tools.js中还包含键最长 1KB值最长 400KBkv_list支持pattern前缀过滤 可选尾部*、return_values、limit/cursor分页offset最大 5000 且不能与 cursor 混用、include_totalkv_remove调用puter.kv.remove(key, ...paths)时会把optConfig作为尾参传入——若传undefined会被当成一个路径因此代码里有专门的参数拼接逻辑kv_get把undefined归一为null返回并提示缺失键与「显式存了 null」用kv_list才能区分。Docs写代码前先查 puter.js 官方文档工具说明puter_docs_index从docs.puter.com/llms.txt加载 puter.js 文档索引每个主题 路径puter_docs_get按主题路径获取指定文档页为 Markdown如Workers/router在 src/tools.js 中resolveDocUrl()会规范化主题 slug去掉首尾斜杠与可选的/index.md/.md后缀拼出https://docs.puter.com/path/index.md如果你直接传 URL它只放行docs.puter.com主机——这是一道防 SSRF 的护栏。由于 Puter Workers 面向「puter.js Puter 认证」设计而非普通裸 HTTP handler工具描述反复提醒 Agent写 Worker 前先用puter_docs_get读Workers/router指南与规范示例。路径约定一切都在主目录之下每个路径都位于你的主目录/username下。工具把路径直接透传给 puter.js因此通行惯例都适用绝对路径/your-username/Desktop/file.txt主目录相对~/Desktop/file.txt相对路径Desktop/file.txt相对于你的主目录解析裸根路径如/portfolio/index.html是无效的——先调用whoami拿到 username再用~/...或/username/...。这个提醒HOME_PATH_NOTE被嵌入到几乎每个路径参数的描述里见 src/tools.js因为它对应 Agent 最常见的一类错误它甚至还告诫不要污染主目录根、应当为项目创建子路径与文件夹。构建、本地运行与部署本地开发cd src/mcp-connector npm install npm run dev # 先构建再 wrangler dev —— 服务在 http://localhost:8787对应 package.json 中的脚本dev npm run build wrangler dev。构建依赖wrangler^4.103.0、webpack、terser-webpack-plugin。构建管线与 src/worker 相同npm run build分两步webpack把 src/index.jsrouter src/mcp.js src/tools.js打成dist/webpackPreamplePart.jsscripts/buildPreamble.mjs处理 template/puter-portable.template 中的#include——拉入src/puter-js/dist/puter.js与上一步的 webpack bundle——产出service-worker 格式的可部署脚本dist/workerPreamble.js。前提src/puter-js/dist/puter.js必须存在。如缺失先在仓库根目录执行cd src/puter-js npm run build构建 puter.js。wrangler.toml 中main dist/workerPreamble.js、compatibility_date 2025-01-01、no_bundle true原因见前文with语句与严格模式的说明。部署到 Cloudflarenpm run deploy # 先构建再 wrangler deploy若要对接自托管的 Puter 实例设置puter_endpoint/puter_gui_origin这两个全局变量取消wrangler.toml中[vars]块的注释[vars] # OVERRIDE_ORIGIN https://mcp.puter.com # puter_endpoint https://api.puter.com # puter_gui_origin https://puter.computer_endpoint文件系统/子域名等调用的 Puter API 源默认https://api.puter.computer_gui_originOAuth「Sign in with Puter」authme重定向所用的 Puter GUI 源默认https://puter.comOVERRIDE_ORIGIN当部署到workers.dev域却希望 OAuth 元数据以自定义域为 origin 时使用。如果要用 OAuth 流程生产环境还必须设置封签密钥作为 secret 而非提交进仓库wrangler secret put OAUTH_SECRET本地wrangler dev在未设置时会回退到内置的不安全默认值见 src/oauth.js该默认值绝不能用于生产。认证两种方式不用复制粘贴 Token两种方式都以调用者身份运行——Worker 不持有任何自身凭据。方式一OAuth「Sign in with Puter」无需复制 Token面向支持 HTTP OAuth 的客户端如 Claude Code此时Worker 本身就是授权服务器。首次使用时客户端会打开浏览器你登录 Puter 并批准随后 Worker 把 Puter Token 交给客户端。具体实现在 src/oauth.js流程为client → GET /authorize → 302 到 puter.com/?actionauthmeredirectURLworker/oauth/callback?flow… 用户在 puter.com 登录并批准Puter 以 ?token… 302 回来 puter → GET /oauth/callback → 302 到 client redirect_uri?code…state… client → POST /token → { access_token: puter token } client → 携带 Authorization: Bearer puter token 发起 MCP 调用无状态性的关键是加密而非持久化authorize→callback 的短命flow与 callback→token 的codeblob 都用OAUTH_SECRET派生的 AES-GCM 密钥封签IV 前置拼接、base64url 编码服务器不落任何盘。TTL 分别为 10 分钟与 5 分钟超时即拒绝FLOW_TTL_MS/CODE_TTL_MS。当客户端提供 challenge 时强制 PKCE 校验支持 S256 与 plainS256 先对 verifier 做 SHA-256 再比对。该模块还实现了完整发现协议GET /.well-known/oauth-authorization-serverRFC 8414 授权服务器元数据及/mcp后缀变体GET /.well-known/oauth-protected-resourceRFC 9728 保护资源元数据及/mcp变体POST /registerRFC 7591 动态客户端注册不持久化客户端安全性依赖 PKCE 封签进 flow 的 redirect_uri。方式二Bearer Token复制粘贴从已登录 Puter 浏览器标签页的 devtools 控制台获取puter.authToken。请像对待密码一样保管它。使用方式是把 Token 放进Authorization: Bearer token头或.mcpb的 token 字段。连接客户端三种接入方式方式 A —— Claude CodeOAuth无需 Tokenclaude mcp add --transport http puter https://puter-mcp.your-subdomain.workers.dev/首次使用时 Claude Code 会打开浏览器完成 Puter 登录批准后即连接成功。若想跳过 OAuth可追加-H Authorization: Bearer YOUR_PUTER_TOKEN。方式 B —— 一键.mcpbbundleClaude Desktop 等本目录维护了一份预构建的 MCP Bundlemcpb 配置导入支持 MCPB 的主机如 Claude DesktopSettings → Extensions → install from file后填写它提示的两个配置字段即可Server URL—— 你部署的 Worker例如https://puter-mcp.your-subdomain.workers.dev/本地wrangler dev则填http://127.0.0.1:8799/Puter Auth Token—— 你的个人 Token作为 secret 存储。.mcpb的生成命令为npm run pack:mcpb # 生成 puter-mcp-connector.mcpb由于连接器是远端 HTTP Worker而 MCPB 扩展运行本地进程bundle 附带了一个零依赖的小型 Node stdio↔HTTP 代理mcpb/server/index.cjs负责把 JSON-RPC 转发给你的 Worker并附上Authorization: Bearer头——代理的配置与清单见 mcpb/manifest.json要求 Node ≥ 18token 字段标注为敏感。.mcpb默认未签名主机可能警告来自未知开发者如需自签名npx anthropic-ai/mcpb sign --self-signed puter-mcp-connector.mcpb方式 C —— 直接 HTTP把任意支持 HTTP transport 的 MCP 客户端指向 Worker URL并把 Token 作为 bearer 头。mcp.json风格示例{ mcpServers: { puter: { url: https://puter-mcp.your-subdomain.workers.dev/, headers: { Authorization: Bearer YOUR_PUTER_TOKEN } } } }用 curl 快速冒烟测试不依赖任何 MCP 客户端框架先验证部署正确性URLhttp://localhost:8787 TOKENyour_puter_token # initialize协商协议版本 curl -s $URL -H content-type: application/json -d { jsonrpc:2.0,id:1,method:initialize, params:{protocolVersion:2025-06-18,capabilities:{},clientInfo:{name:curl,version:0}} } # 列出全部工具 curl -s $URL -H content-type: application/json \ -d {jsonrpc:2.0,id:2,method:tools/list} # stat 你的主目录需要 Token curl -s $URL -H Authorization: Bearer $TOKEN -H content-type: application/json -d { jsonrpc:2.0,id:3,method:tools/call, params:{name:fs_stat,arguments:{path:~}} } # 写入再读取一个文件 curl -s $URL -H Authorization: Bearer $TOKEN -H content-type: application/json -d { jsonrpc:2.0,id:4,method:tools/call, params:{name:fs_write_file,arguments:{path:~/Desktop/hello.txt,content:hi from MCP}} } # 列出已托管的网站 curl -s $URL -H Authorization: Bearer $TOKEN -H content-type: application/json \ -d {jsonrpc:2.0,id:5,method:tools/call,params:{name:hosting_list,arguments:{}}}逐段解读请求 1 完成 MCP 握手请求 2 应返回 src/tools.js 中定义的全部工具及 JSON Schema请求 3–5 分别验证「以你的 Token 身份」的文件系统与托管域。注意第一个请求故意不带 Token——tools/list之前的认证策略是initialize与tools/list本身公开真正的工具调用tools/call在没有user.puter时会以内联 toolErrorMissing Authorization: Bearer header.返回方便客户端直接把错误显示出来 src/mcp.js。安全设计要点小结从源码可以确认这套连接器把「多租户 无凭据」做到了很细的颗粒度值得在自托管时留意按调用者隔离每个请求独立的with上下文 独立 puter.js 实例Token、缓存互不共享template/puter-portable.template响应防缓存泄漏用户数据一律Cache-Control: no-store仅公开发现端点允许public, max-age300src/mcp.jsOAuth 防重放所有授权端点响应带no-storeflow/code 用OAUTH_SECRETAES-GCM 封签且带 TTLsrc/oauth.js外呼目标白名单workers_exec仅允许https://*.puter.workputer_docs_get仅允许docs.puter.com主机杜绝 SSRF 与 Token 外泄危险操作收敛KV 不暴露flush签名上传会话失败自动 abort避免悬挂资源fs_delete之外的删除类工具都不触碰源文件/站点hosting_delete、workers_delete、apps_delete均如此。结合 src/worker本项目的被分叉来源与 src/puter-js被内联的真实 puter.js SDK对照阅读可以更完整地理解这套「把整套 Puter 能力装进一个无状态 Worker」的移植思路。若要在生产中使用 OAuth 流程务必设置wrangler secret put OAUTH_SECRET若对接自托管 Puter则按上文配置puter_endpoint/puter_gui_origin。【免费下载链接】puter The Internet Computer! Free, Open-Source, and Self-Hostable.项目地址: https://gitcode.com/GitHub_Trending/pu/puter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考