Sub2sub

sub2sub

Keep the user in their current working conversation. Use 共享端 / Host for a device sharing AI capabilities and executing authorized tasks, and 使用端 / Client for a device delegating work and receiving results. A device may serve both roles. Map these names to existing provider / caller tool fields and values; keep their API names unchanged. Call Codex or Claude Code the managing app or AI tool when discussing the plugin's application host.

A paired host executes using its selected Codex or Claude subscription. Both devices use compatible plugin versions. Private-network connections work directly; cross-network connections require both devices to explicitly enable the device-wide service. Codex Desktop, Codex CLI and Claude Code load the same task tools through their own plugin installation. The managing app and the host's execution tool are separate choices. Claude clients and macOS Claude hosts do not need local Codex; Claude execution requires native Claude Code 2.1.263+ and subscription login.

First-use settings

When first-use settings are pending, briefly explain how to use sub2sub before the complete settings summary: the receiving computer creates an invitation; the sending computer connects and approves file transfer; the user delegates from their current conversation, receives local files and answers, and continues the same task there. Mention that cross-network use requires both devices to opt in. Use a short paragraph in the user's language and then continue the existing request. A returning user does not need this introduction again. When the user asks for usage help, explain these steps with one small file-task example and point to “Help” in local management; opening help does not start sharing or change settings.

Before acting in a new conversation, call onboarding with no arguments. When confirmationRequired=true, clearly say that first-use settings need approval, even if the user already supplied an explicit task. Show the complete returned summary in the user's language: both roles; Codex and Claude client defaults; automatic host selection and ordered candidates; host execution tool and each tool's model restrictions; both roles' input/result byte and file limits; retention and cleanup conditions; device name, advanced paths and supported limits; connections and their transfer consent; authorized clients; current sharing state; cross-network service state and its default-off behavior. Explain unset choices and unverified model availability as returned. This first summary includes advanced settings; later ordinary settings queries can stay concise.

Wait for the user to approve that summary, then call onboarding(action=confirm) and continue the original request with its existing arguments. An onboarding_required response means the requested action has not run; use its summary and retry that action after the decision. Keep the original request in the conversation so the user need not repeat it. Settings confirmation is separate from task-file consent below.

For requested changes, use the existing settings tools, refresh the summary, and ask for approval of the changed settings. Keep unset Claude defaults unset until a connected node's live catalog is available and the user chooses. The guide itself does not need a local execution tool or query model availability.

Record action=skip only when the user explicitly skips the guide. action=reopen presents it again without resetting settings. Interrupted introductions remain pending across conversations. existing, confirmed and skipped require no repeated first-use approval; proceed with the intent below.

Cross-network service

Use device_settings(crossNetwork=true|false) only for an explicit device-setting request. Before enabling, explain that both devices must opt in, private connections are preferred, and public discovery/relay services can affect privacy, speed and availability. File consent and task execution permissions remain separate. A sharing or pairing request alone leaves the setting unchanged.

For an explicitly requested existing-connection migration, call edit_peer(peer, migrate=true) after both devices enable the service. If the old endpoint is unreachable, request a new invitation from the same host and pass invitation; the original pairing must verify before saving. Keep the old connection on failure. See installation and compatibility when an older version or missing helper prevents migration.

When disabling or exiting is rejected for active work, transfers or unresolved submissions, report the original task and actual enabled state. Help finish and collect it, or cancel only when the user explicitly requests cancellation. Retry the setting change after resolution. Do not abandon, delete, re-pair or resubmit an uncertain task to bypass this protection.

Start with intent

• Check or install updates: call update_plugin with action=check for a read-only check, or action=install only when the user explicitly asks to upgrade. Use installation app metadata; if absent, ask which managing app (Codex or Claude) they want to update, never infer it from the host execution tool. Report current session, registered installation, running node and latest release separately. On deferred, explain the missing condition and preserve tasks. On installed, follow nextStep: Codex Desktop must fully quit and reopen; closing its window or starting another conversation is insufficient. Codex CLI and Claude Code need an exit and restart. Independent nodes activate the new version only through their existing idle exit/start actions; never restart automatically. See ../../docs/install.md for the 0.5.3 transition.

• Open or disable management: use web_management(enabled=true) when asked to open the page, then show/open the returned private local URL. Use enabled=false when asked to close the management service; omit arguments to inspect it. The page defaults on in each MCP process and ends with that process. It is local-only and does not automatically open a browser; switching it off preserves independent sharing. Keep the URL private. Tasks and follow-ups remain in the working conversation.

• Resource statistics: use resource_statistics with the requested client/host role and 7/30-day period. Explain task versus round counts, measured time, native model usage and incomplete/old records. Use usageDetails for requested per-turn details or file export; include scope, source, actual versus requested model, null fields and usagePendingTasks. Cached and reasoning classifications can overlap other fields; never add them again or infer missing totals. Both sides describe the same consumption, not two sets to add. Work-copy cleanup retains statistics; explicit record deletion removes them. Client figures cover received records, not unseen remote activity. Keep account quota separate.

• Troubleshoot or submit feedback: read focused diagnosis and feedback. Select the existing checks relevant to the reported symptom, prepare public-safe findings, and use the managing app's existing GitHub capability only when submission is requested.

• Getting started: after the settings review, explain three steps: the host says “生成邀请码”; the client pastes it and agrees to the task-file scope; then says “把这个任务交给〈节点名称〉”. Sharing runs in an independent node after startup; the management conversation can close. Keep the device awake and connected, and start sharing manually after reboot. Codex defaults to GPT-5.6 Luna / max. If Claude client defaults are unset, list the target node’s models and ask the user to choose model and effort before sending files; offer to save that choice. A host offers all available models for its selected tool.

• Share / invite: call create_pairing directly. Use the current device setting; generating an invitation does not authorize enabling cross-network service. If the user explicitly requests an existing private/VPN interface, use its actual IPv4 address. It starts or reuses this machine's sharing process. Return the private, single-use invitation and its ten-minute lifetime. Use setup_status only when address selection fails. Pairing does not select a task model.

• Connect: explain the consent below, then call pair_peer with the user's allowTaskFiles decision. Omit peer to follow the host device name; supply an explicit alias only when the user chooses one. Success confirms connectivity; report the peer without another routine check.

• View saved results: read the local delivery format, call list_tasks, identify the task by peer and times, then read/open its local workCopyDirectory, responseFile and resultDirectory/changes.json. Include Markdown links to the main local output and responseFile, with full absolute targets, alongside the saved answer; disclose failed/interrupted execution and any skipped necessary outputs from the saved manifest. This works after remote cleanup or disconnection. Viewing does not call collect_result, task_status, SSH or another remote access tool. If deliveryPending=true, explain that the listed files are the previous save; absent freshness information in older records is unknown.

• Device name, local space or manual local deletion: read settings and management.

• Settings or status: read settings and management. Keep 使用端 and 共享端 separate; show ordinary settings first and advanced settings only when requested or needed to resolve a concrete limit.

Consent once per destination

Before enabling task-file transfer, explain in the user's language:

以后你委托给这台电脑的任务，会发送所需文件和指令，可能包含非公开项目源码、文档和必要配置，共享端可以接触这些材料。密码、密钥、订阅凭据、无关文件不在授权内；其他敏感材料需另行确认。默认到期清理只在成果已取回且没有执行中的工作后删除工作副本，保留原生会话历史；如共享端启用全部到期清理，须同时接受其具体规则。你可以随时撤回后续传输授权，但撤回或清理不能收回对方已复制、备份的内容。是否同意？

Set allowTaskFiles=true only after explicit agreement. For an existing peer without a grant, obtain this decision and use authorize_peer; preserve a refusal or withdrawal. Never edit configuration to manufacture consent.

When pairing or a capability check returns retentionPolicy, include its exact idle duration, deletion of uncollected results and associated native history, and loss of original-session continuation in this consent. Pass the returned policy to authorize_peer only after acceptance. An unchanged accepted rule needs no extra per-task confirmation; changed rules require renewed consent before new uploads. Pairing alone and old clients do not accept full expiry.

An existing task-files grant covers necessary ordinary project source, documentation, configuration and instructions. Show destination, scope and size once, then proceed within that grant. Select necessary materials and respect the existing credential-path exclusions; ordinary text is not scanned for secrets, so exclusions do not guarantee all sensitive content is detected. New destinations or separately sensitive material outside the grant need their own consent.

Application consent does not override managing-app approval. Pass an explicit peer to prepare_work_copy for manual selection; enabled automatic selection instead returns all candidate destinations and their separate consent. Show that scope to the managing app. For separately sensitive materials, obtain consent for each eligible destination or restrict this task to the approved peer. If managing-app approval rejects a transfer, report its action and reason and obtain the required permission; do not change transport or settings to bypass that rejection.