## Thinking Path Paperclip coordinates an external Grok Bot through its authenticated agent connection and routine. The shared configuration form only excluded OpenAI Dot from local runtime controls, so Grok Bot inherited a model picker, local paths, an AI account picker, and a generic runtime test. These controls cannot configure the external Bot and the generic test is not evidence of its webhook-to-MCP connection. Extend the existing external-provider presentation gates and retain the dedicated connection verification workflow. Related implementation: #16219 and #16305. Searched open Grok PRs and issues; the remaining matches concern the separate coding runtime or unrelated coverage. ## Linked Issues or Issue Description **What happened?** An existing Grok Bot agent's Runtime page shows local model and runtime configuration alongside its actual external connection controls. **Expected behavior** Identify the harness as Grok Bot, show its connection and routine controls, and use Verify connection for authenticated two-way readiness. Omit inapplicable local-runtime controls and model catalog queries. **Steps to reproduce** Create a Grok Bot through Invite external agent, then open its Runtime settings. Before this correction, the shared form renders a model selector and Test your agent despite the Bot owning its runtime. **Paperclip version/commit** Master after #16219; reproduced against the shared form at8ffc5748a2. ## What Changed - Treat Grok Bot and Dot as external providers when resolving local configuration and model catalog queries. - Identify Grok Bot directly in the harness field and keep its dedicated connection, routine, and verification controls. - Hide the generic runtime test for Grok Bot, including compact feedback and externally registered test actions. - Add regressions for compact and inline configuration and production ConfigurationTab stories for connected, disconnected, and mobile states. - Isolate generated documentation previews in separate iframes; verified connected and disconnected states remain distinct across polling. - Document the Runtime management path. ## Verification - New regression failed in both variants before the correction; the four focused UI suites pass: 131 tests, including existing native-provider configuration coverage. - Repository typecheck, production build, and token gates pass. Storybook builds successfully. - Used the built production ConfigurationTab in the browser: connected health, credential replacement fields, disconnected reconnect, and a 375-pixel mobile layout with no horizontal overflow. These are synthetic connection fixtures, not live-provider qualification. - A full local database-backed suite is unavailable because this Mac has reached its SysV shared-memory limit. The earlier diagnostic fixture confirmed that limitation; no unrelated databases were stopped. Full repository CI passes on60119f1ce1: 55 checks successful and two intentional skips. - Fresh Greptile review is 5/5 on the final head, with the preview-isolation finding addressed and its thread resolved. ## Risks Low risk: shared form presentation and unnecessary model queries change; no authorization, secret storage, Runner execution, schema, or transport behavior changes. Existing stored configuration remains intact. Native-provider form regressions run in the focused suite; full repository CI passes on the final head. ## Model Used OpenAI Codex, based on GPT-6, with repository inspection, code editing, shell tests, and browser verification. The host does not expose a more specific serving-model ID or context-window size. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [x] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
3.3 KiB
Grok Bot agents (experimental)
Grok Bot is an externally managed Paperclip agent. It uses Grok Bot's existing apps and persistent context. It is separate from the Grok Build coding runtime. Paperclip coordinates tasks through the managed Runner. Grok usage and spending are not reported.
From Agents → New agent → Invite external agent → Grok Bot, name the agent and select its role and manager. Follow the connection instructions in Grok Bot. Approve the fixed Paperclip company and agent in the browser. Copy the one-use pairing code with Copy code; enter it only on the authorization page. Grok plugins are account-wide, so connecting a Bot does not isolate credentials between Bots on that Grok account.
Copy the routine instructions into the Bot's chat. Open its desktop routine's Webhook panel and paste the URL and key into Paperclip's secure configuration. Use a webhook-only routine with no schedule. Verify connection must show both assignment delivery and an authenticated reply before Done becomes available. Use Save & exit to preserve unfinished setup. See the official routine instructions.
Manage the Bot from its agent's Runtime settings. This shows connection health, routine configuration, and verification. Model selection, local paths, and runtime tests are managed outside Paperclip; use Verify connection to check both directions.
Assign ordinary tasks to the agent. Read its progress, answer its question cards, and review its documents and files in the task thread. The Bot can initiate a new task from its Grok conversation through the admitted work-session tools. An immediate proactive claim does not send the same assignment back through the routine.
Files and completion
Use paperclip_grok_get_upload_url for an accepted current assignment. Compute
the exact file's SHA-256 and size, then PUT those bytes with Grok's own HTTP/file
tools. The successful response includes the attachment and its verified
publication.evidenceRef. Cite that reference in the completion report. No
Paperclip filesystem is exposed, and no separate upload completion call is needed.
Repeat the same request ID after a lost response. Concurrent or repeated uploads
retain one attachment and one publication receipt. Person MCP uploads remain
person uploads; they do not gain agent execution or publication authority.
The upload checks current grant, company, agent, task, work session and work mode. Publication also verifies stored filename, byte size and SHA-256. Normal Runner completion verifies that receipt against the upload and admitted assignment. A visible attachment without that verified publication does not satisfy a task that requires a file output.
Recovery and stop
Inspect a rejected delivery before using Retry rejected delivery. An uncertain outcome needs inspection and explicit recovery; it is never sent again automatically. Saved work remains on the task if execution fails. Reverify after clearing an inspected recovery hold before admitting another assignment.
Stop Paperclip work immediately revokes the session's Paperclip authority and stops future dispatch. Remote Grok execution may continue. Open the Grok Bot app to inspect it. Paperclip shows reported activity, not a complete remote transcript or computer recording.