PaperClipAI

0 Fork 0

mirror of https://github.com/paperclipai/paperclip.git synced 2026-10-26 18:31:34 +01:00

Author	SHA1	Message	Date
DottaandPaperclip	8fa5d2d6b6	test(gateway): provision grant for elicitation fixtures Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-21 01:55:23 +00:00
DottaandPaperclip	ce5791dd03	test(connections): route MCP fixtures through test transport Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-21 01:55:23 +00:00
DottaandPaperclip	9fd0a1b9c7	fix(connections): preserve reconnect approval gates Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-21 01:55:23 +00:00
DottaandPaperclip	a256d2ebd7	test(connections): stabilize grant PR verification Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-21 01:55:23 +00:00
DottaandPaperclip	f5cbb2ac57	Merge origin/master into connection grant resolution Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-21 01:55:23 +00:00
Devin Foley	db4defdfbf	feat: operator-configurable settings visibility via PAPERCLIP_HIDDEN_SETTINGS (#11823 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - The instance settings surface (Access, Plugins, Adapters, General, Experimental) assumes the person at the keyboard operates the whole instance > - Operators who host Paperclip for others — a managed cloud or an internal shared server — expose settings pages and toggles that do not apply to their deployment, and the related mutation APIs stay open > - A hosted tenant can open Plugins or Adapters, try an action, and hit a confusing failure, because only a few hardcoded platform floors exist > - This pull request adds a generic, operator-configured visibility mechanism: one env var hides declared settings surfaces in the UI and floors their mutation routes with a stable 403 code > - The benefit is a clean hosted-tenant settings surface for any operator, with zero behavior change for normal self-hosted instances ## Linked Issues or Issue Description Subsystem affected Instance settings (server routes and UI), the shared settings registry in `packages/shared`, and the `/api/health` bootstrap payload. Problem or motivation An operator who hosts Paperclip for other people cannot hide settings surfaces that the platform manages. Tenants see Access, Plugins, and Adapters pages, backup retention, and host-level experimental toggles that do nothing useful for them. The mutation APIs behind these surfaces also stay open, so a tenant admin can attempt actions the platform must control. ROADMAP.md names a cleaner shared deployment story as a goal ("Teams should be able to run the same product in hosted or semi-hosted environments without changing the mental model"). Proposed solution Add a declarative registry of hideable settings surfaces and one env var, `PAPERCLIP_HIDDEN_SETTINGS`. The server parses the list at boot, reports it on `/api/health`, and rejects value-changing writes to hidden surfaces with a stable `settings_operator_managed` 403 code. The UI reads the list from the health payload and removes the hidden pages, sections, and toggles from navigation, routes, and page content. Unknown keys warn and are ignored, so one list can roll across a fleet with mixed app versions. With the variable unset, behavior is byte-identical to today. Alternatives considered - Hardcode the hidden set for cloud instances in this repo: rejected, because each hosting operator needs a different policy, and policy does not belong in shared code. - Deliver the hidden set through the managed-config document: rejected, because that channel is cloud-specific and fail-closed on unknown fields; a plain env var works for any operator, including self-hosted shared servers. - Lock the controls with a badge instead of hiding them: rejected for these surfaces, because they are meaningless to tenants, not merely platform-controlled; the existing managed-overlay lock stays the right tool for controlled flags. Roadmap alignment Supports the "shared deployment story" item in ROADMAP.md: hosted and semi-hosted deployments keep the same product with a settings surface that matches what the tenant can actually do. ## What Changed - New `packages/shared/src/settings-visibility.ts`: registry of hideable surfaces (every instance settings page — profile, environments, access, heartbeats, experimental, plugins, adapters; every Instance → General section; every experimental flag as `instance.experimental.<key>`), the `PAPERCLIP_HIDDEN_SETTINGS` parser, and the `settings_operator_managed` error code. The General page stays visible as the settings root and redirect target. - New `server/src/services/settings-visibility.ts`: parse-once accessor; unknown keys log one warning and are ignored. - `/api/health` reports `hiddenSettings` on every response shape; the field is omitted when nothing is hidden. - Server floors on hidden surfaces, with same-value echo tolerance (the `executionMode` precedent): field-backed general sections and experimental keys reject value-changing PATCHes, and hiding the whole Experimental page floors every toggle; plugin lifecycle and config writes, adapter management writes, and the Access admin routes (reads included) return 403 `settings_operator_managed`. Reads the app itself needs (plugin `ui-contributions`, adapter metadata, plugin job trigger) stay open. Pages without instance-scoped mutation routes are hidden in the UI only. - UI: new `useHiddenSettings` hook and `HiddenSettingsPageGate` route gate (hidden pages redirect to the settings root); the settings sidebar and tab bar drop hidden entries; remembered settings paths remap to the default page; `InstanceGeneralSettings` skips hidden sections; every `ExperimentalToggleCard` now carries its flag key and renders nothing when hidden. - Removed the dead `InstanceSidebar` component (referenced only by its own test). - Docs: `docs/deploy/environment-variables.md` documents the variable and the key registry. ## Verification - `pnpm vitest run` over the new and extended suites: shared registry and parser, representative floor tests per route class (changed-value 403, same-value echo 200, unset env 200, page-level Experimental hiding), the health field, the route gate, nav filtering, and section/card hiding with one hidden example per surface kind — 168 tests pass. - Full root `pnpm typecheck` passes. - Manual: booted a server with the variable set. `/api/health` lists the keys; an unknown key logs one warning and the server boots; hidden pages redirect; hidden sections and cards do not render; hidden-field PATCH returns 403 with `details.code = "settings_operator_managed"`; a same-value echo returns 200. Unset the variable: the full settings surface returns and responses are byte-identical to master. ## Risks - Low risk for self-hosted instances: with the variable unset, the hidden set is empty, the health field is omitted, and no floor activates. - Flooring plugin config writes assumes hosted deployments configure plugins through the platform. If a future bundled plugin needs tenant-entered config, the floor needs a narrow carve-out. - Hidden-key floors tolerate same-value echoes, so API clients that round-trip full GET responses keep working. - Hiding a toggle does not change its value; operators pair hiding with the desired default where the value matters. ## Model Used Claude Fable 5 (Anthropic, `claude-fable-5`) with extended thinking and agentic tool use, driven through the Claude Code CLI (file edits, test execution, and live-server verification loops). ## 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 - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 17:54:44 -07:00
Michael Nguyen	0fa318b8da	feat(artifacts): bridge Markdown work products into the document review surface (#11822 )	2026-08-20 17:28:01 -07:00
nearfolk	c2cfd55e97	fix: exclude thought text from automatic issue comments (#11801 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The heartbeat system records agent runs and can add a run summary to an issue. > - The ACPX engine receives output text and internal thought text as separate streams. > - The default summary strategy joined both streams and could publish internal text in an issue comment. > - Paperclip already has final-output segmentation for run summaries. > - This pull request makes final-output-only summaries mandatory and removes the configuration bypass. > - The benefit is that automatic issue comments contain the intended final message instead of internal execution text. ## Linked Issues or Issue Description Refs #11761 What happened? The ACPX engine used the full summary strategy when an adapter did not set `summaryStrategy`. That strategy joined all text deltas, including thought-stream text and intermediate narration. The heartbeat finalizer could then store that summary as an issue comment. Expected behavior An automatic issue comment must use only the final output segment. Configuration must not allow thought-stream text or intermediate narration into that summary. Steps to reproduce 1. Run an ACPX adapter without a configured `summaryStrategy`. 2. Emit an output delta, a thought delta, a tool call, and a final output delta. 3. Read the generated run summary. 4. Observe that the old default included all text deltas. Paperclip version or commit `54b8bec44417511c623999613f9f1006f8af0517` Deployment mode Built from source with a local ACPX adapter. ## What Changed - Limit ACPX run summaries to the final non-empty output segment. - Ignore the legacy full-summary setting so configuration cannot bypass containment. - Update regression tests for the safe default and an attempted unsafe override. ## Verification - Observed the new guard fail before the implementation change because the summary contained thought text. - Ran `pnpm exec vitest run packages/adapter-utils/src/acpx-engine/execute.test.ts -t "defaults run summaries to the final output segment without thought text\|does not allow configuration to include thought text in run summaries"`. Result: 2 passed. - Ran `pnpm exec vitest run packages/adapter-utils/src/acpx-engine/execute.test.ts`. Result: 130 passed. - Ran `pnpm --filter @paperclipai/adapter-utils typecheck`. Result: passed. ## Risks - Run summaries are shorter for adapters that relied on full text aggregation. - The old `summaryStrategy: "full"` setting no longer changes summary behavior. This is an intentional containment change. - The change does not alter run logs or tool events. It changes only the summary selected for downstream use. > This is a focused security and privacy bug fix. It does not add roadmap scope. ## Model Used - OpenAI Codex on the GPT-5 family. The runtime did not expose the exact model ID or context-window size. Reasoning, tool use, terminal execution, and code editing were enabled. ## 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 and contains no internal task id - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant inline documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [ ] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [ ] I will address all Greptile and reviewer comments before requesting merge	2026-08-20 15:48:34 -07:00
dependabot[bot]Priya Raman Paperclip	f674f2ca31	build(deps): bump chokidar from 4.0.3 to 5.0.0 (#11720 ) Bumps [chokidar](https://github.com/paulmillr/chokidar) from 4.0.3 to 5.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/paulmillr/chokidar/releases">chokidar's releases</a>.</em></p> <blockquote> <h2>5.0.0</h2> <ul> <li>Make the package ESM-only. Reduces on-disk package size from ~150kb to ~80kb</li> <li>Increase minimum node.js version to v20.19. The versions starting from it support loading esm files from cjs</li> <li>fix: Make types more precise <a href="https://redirect.github.com/paulmillr/chokidar/pull/1424">paulmillr/chokidar#1424</a></li> <li>perf: re-use double slash regex <a href="https://redirect.github.com/paulmillr/chokidar/pull/1435">paulmillr/chokidar#1435</a></li> <li>Update readdirp to ESM-only v5</li> <li>Lots of minor improvements in tests</li> <li>Increase security of NPM releases. Switch to token-less Trusted Publishing, with help of <a href="https://github.com/paulmillr/jsbt">jsbt</a></li> <li>Switch compilation mode to isolatedDeclaration-based typescript for simplified auto-generated docs</li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/mhkeller"><code>@mhkeller</code></a> made their first contribution in <a href="https://redirect.github.com/paulmillr/chokidar/pull/1426">paulmillr/chokidar#1426</a></li> <li><a href="https://github.com/btea"><code>@btea</code></a> made their first contribution in <a href="https://redirect.github.com/paulmillr/chokidar/pull/1432">paulmillr/chokidar#1432</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/paulmillr/chokidar/compare/4.0.3...5.0.0">https://github.com/paulmillr/chokidar/compare/4.0.3...5.0.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/paulmillr/chokidar/commit/c0c8d20e49d337491891078d1081bf91bd178de6"><code>c0c8d20</code></a> Release 5.0.0.</li> <li><a href="https://github.com/paulmillr/chokidar/commit/b211ceca34b1d30326334de21ed30b4a4ceb4c7e"><code>b211cec</code></a> Remove src from npm</li> <li><a href="https://github.com/paulmillr/chokidar/commit/87422468fd353426a53a78788b8718979c8725cc"><code>8742246</code></a> Upgrade dev deps, jsbt, ci files. Upgrade readdirp to v5.</li> <li><a href="https://github.com/paulmillr/chokidar/commit/de5a34c3cccf2d6fc812a6080e29fb4dd1583ec1"><code>de5a34c</code></a> Merge pull request <a href="https://redirect.github.com/paulmillr/chokidar/issues/1442">#1442</a> from paulmillr/flaky-buns</li> <li><a href="https://github.com/paulmillr/chokidar/commit/c08a6c4ed6a67b2cb16f61592f763b33e6bce7d3"><code>c08a6c4</code></a> fix: throttle based on dir + target</li> <li><a href="https://github.com/paulmillr/chokidar/commit/0c55ab3b049682fae9c1ee278ebc964dbfb92f08"><code>0c55ab3</code></a> test: wait for explicit calls in directory test</li> <li><a href="https://github.com/paulmillr/chokidar/commit/ce81be5a51ae72920649e2a74aeba86688c2a5ee"><code>ce81be5</code></a> perf: re-use double slash regex (<a href="https://redirect.github.com/paulmillr/chokidar/issues/1435">#1435</a>)</li> <li><a href="https://github.com/paulmillr/chokidar/commit/7d9c1ed27d2b9150077601677a8a8bad27b8f3da"><code>7d9c1ed</code></a> Merge pull request <a href="https://redirect.github.com/paulmillr/chokidar/issues/1433">#1433</a> from paulmillr/super-matrices</li> <li><a href="https://github.com/paulmillr/chokidar/commit/391554143f582fe78f7d37cf54b834c42f84652b"><code>3915541</code></a> Merge pull request <a href="https://redirect.github.com/paulmillr/chokidar/issues/1430">#1430</a> from paulmillr/esm-only</li> <li><a href="https://github.com/paulmillr/chokidar/commit/9308bedee986abac912100e4bcc4823a1504a10f"><code>9308bed</code></a> chore: use Nodejs 24 in CI (<a href="https://redirect.github.com/paulmillr/chokidar/issues/1432">#1432</a>)</li> <li>Additional commits viewable in <a href="https://github.com/paulmillr/chokidar/compare/4.0.3...5.0.0">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~GitHub%20Actions">GitHub Actions</a>, a new releaser for chokidar since your current version.</p> </details> <br /> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Priya Raman <priya@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-20 15:28:55 -07:00
DottaandPaperclip	51096d303f	fix(apps): apply ask-first defaults in gallery setup Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 22:18:18 +00:00
DottaandCodex	13dd4c1eae	fix(apps): preserve grant and approval defaults Co-authored-by: Codex <codex@openai.com>	2026-08-20 22:11:52 +00:00
Dotta Paperclip Claude Opus 5	cb0009b097	fix: preserve recovery retries across restarts (#11817 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The control plane must keep each active issue on a clear execution or recovery path. > - A missing issue disposition can require more than one bounded repair attempt. > - A server restart could lose that repair path or move source ownership to the recovery owner. > - A parked or expired retry could also make the user interface show a false healthy state. > - Concurrent recovery loops must not schedule the same repair attempt twice. > - This pull request keeps retry state durable, makes scheduling atomic, and keeps source ownership stable. > - The benefit is that recovery continues after a restart and operators see the correct state. ## Linked Issues or Issue Description What happened? A run that ended without a valid issue disposition could lose its repair path after a server restart. Manager recovery could also change the source owner. In addition, a parked or expired retry could make the issue look healthy when no active work existed. Concurrent reconciliation could also schedule the same repair attempt twice. Expected behavior Paperclip must keep bounded source and manager repair attempts across restarts. Recovery ownership must stay separate from source issue ownership. The server and user interface must report only a live retry as active work. Each repair attempt must be scheduled at most once per company. Steps to reproduce 1. Start an agent run on an issue. 2. End the run without a valid issue disposition. 3. Let the first repair attempt schedule a retry. 4. Restart the server, let the retry time pass without a live run, or start two reconciliation loops together. 5. Observe that the repair path can stop, the issue can show a false healthy state, or duplicate retries can be created. Paperclip version or commit The problem existed on `master` before candidate head `d8e620fe86bade7df18decac332007f5821ae04f`. Deployment mode The problem affects self-hosted servers and local builds that use automatic recovery. ## What Changed - Persist bounded source-owner and manager repair lineages with stable fingerprints and retry limits. - Resume incomplete disposition repairs after a server restart. - Keep recovery ownership separate from source issue ownership and enforce source mutation authority. - Project live retry evidence into issue and blocker summaries. - Show recovery owner, return owner, attempt count, and retry state in the board user interface. - Treat expired or parked retries as attention states unless a queued or running attempt exists. - Atomically deduplicate disposition-repair wake requests with a company-scoped partial unique index. - Reuse the winning run when concurrent reconciliation loses the uniqueness race, without duplicate scheduling activity. - Honor disabled on-demand wake policy before recovery scheduling and again before delayed retry promotion. - Keep the new index migration safe for lagging seeded databases that already contain the index. - Add server and user interface tests for recovery, restart, ownership, retry, concurrency, and blocker states. - Update the implementation and execution semantics documents. ## Verification - Focused server recovery and ownership suites: 282 tests passed on the repaired base candidate. - Focused user interface recovery suites: 128 tests passed on the repaired base candidate. - Atomic-deduplication schema and recovery suites: 111 tests passed on the first Greptile repair. - Recovery and scheduled-retry wake-policy suites: 126 tests passed at `d8e620fe86bade7df18decac332007f5821ae04f`. - The exact lagging-source migration-order test passed after the index migration became idempotent: 1 test passed and 62 unrelated tests were skipped. - `@paperclipai/db` and `@paperclipai/server` typechecks passed at the current head. - Migration generation and migration safety checks passed for migration `0226_tan_colossus.sql`. - `pnpm check:token-gates` passed on the repaired base candidate. - `pnpm -r typecheck` passed on the repaired base candidate. - `pnpm build` passed on the repaired base candidate. - `pnpm test:run` passed 4,540 tests on the repaired base candidate. Four fixed-port cases met listeners that already existed on the host. - The two unchanged fixed-port files passed in an isolated network namespace: 129 tests passed and 27 tests were skipped. - Independent Security and QA reviews approved `63c0423aab54c66f2293a20b0fb3f3b013ee3ba8`; exact-head re-review is required after automated checks settle on `d8e620fe86bade7df18decac332007f5821ae04f`. ## Risks - Recovery orchestration affects issue liveness and ownership. The new paths use bounded attempts, stable fingerprints, row locks, authority checks, and database uniqueness. - A conservative attention state can show more warnings when a scheduled retry has no queued or running attempt. It does not hide stopped work. - Migration `0226_tan_colossus.sql` creates a partial unique index on a known-large table. Migrations run transactionally, so `CONCURRENTLY` is unavailable. The matching disposition-repair key namespace is introduced by this release, so deployed databases have no matching rows before the index is added. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - OpenAI Codex from the GPT-5 model family used agentic reasoning, tool use, and code execution. The runtime did not expose the exact model ID or context window. - Anthropic Claude Opus 5 used a 1M context window, tool use, and code execution for part of the user interface repair, as recorded in the commit history. ## 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> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 17:09:42 -05:00
DottaandPaperclip	756dd2fbde	fix(apps): mediate stdio credentials through grants Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:47:36 +00:00
DottaandPaperclip	6d4e65f621	fix(smoke-lab): seed organization grants Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:39:40 +00:00
DottaandPaperclip	89468893b9	feat(apps): resolve credentials through grants Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:23:02 +00:00
DottaandPaperclip	1880c9d21e	feat: enforce connection access permissions Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	5f7926a5d5	fix(apps): include connection lifecycle activity Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	8ed119deb6	fix(apps): aggregate connection activity Read the cross-app activity feed from the canonical tool call events used by each connection, preserving filters, pagination, gateway scope, and redacted invocation details. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	84c2b30358	feat(apps): confirm connections and cache MCP actions Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	e598c41771	fix(apps): preserve MCP follow-ups after master sync Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	51e5195135	fix(workspaces): bind commands to configured runtime rows Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	142bcdd1c7	fix(workspaces): restore managed runtime origin hint Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	3d3a12a3e2	fix(workspaces): keep inventory reads DB-only Backport the existing master guard so this long-lived feature worktree does not fan out Git scans across its cloned workspace inventory. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
Dotta	b4b59388e5	fix(auth): support managed loopback session cookies	2026-08-20 21:20:02 +00:00
DottaandPaperclip	faaa0ce428	fix(apps): complete MCP connection follow-ups Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	ca94577206	feat: enable MCP tools by default Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	18d160d66a	fix(oauth): fall back from private CIMD origins Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	b0515d65a2	fix(security): guard connection token brokers Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	bfc8fd81af	fix(oauth): return failed callbacks to setup Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandClaude Opus 5	1d000bc903	fix(security): make removing an app revoke its credentials Removing an app only flipped the connection to `archived`. Everything that made it work stayed behind: the operator's pasted key or OAuth tokens as live secrets, the `company_secret_bindings` that project them into runtimes, the install, the app-managed `app:<connectionId>` profile, gateway tokens minted against that profile, and any authorization still in flight. Reconnecting reused the retained credential, so "remove" never actually revoked anything. Removal is now a teardown, and the order is the security property. Every database-side access path closes first — grants revoked, bindings and installs deleted, the app profile removed (archived instead when a gateway's RESTRICT foreign key forbids deleting it, with that gateway's tokens and sessions revoked), live local runtimes stopped, catalog entries marked `removed`, outstanding OAuth state discarded, the connection and its application archived — so the app is undispatchable before the first call out to a secret provider. Only then are the credentials revoked, and each secret's ref survives until that secret is gone: a provider that errors leaves the operation failed closed and resumable, because the secret row is marked deleted before the provider call and the surviving refs are what a retry reads to finish the job. A secret is destroyed only when two independent tests agree: it was minted into the `tool_app.` namespace by connect/reconnect/OAuth, and nothing outside this connection references it. Anything ambiguous keeps its row and is reported as retained — deleting a credential another target still resolves is an outage, retaining an unreachable row is not. What stays is deliberate. Connection and application identity, names and activity survive so a reconnect reuses them, but with no credential, install or profile, reconnecting has to ask for fresh authentication and rebuild access. The activity receipt carries cleanup counts only; six of those count keys name what they counted ("secrets", "token"), so `sanitizeRecord` lets them through while the value is a finite number and still blanks the same key carrying anything else. Refs PAP-17119, PAP-17118, PAP-17089 (QA finding F6). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	ba603abace	fix(apps): guide generic MCP connection failures Map OAuth origin, duplicate-name, and DNS failures to stable operator guidance, and derive collision-resistant defaults from host, port, and path. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	048c3578e3	fix(server): enforce MCP wizard action scope Prevent connection installs from adding connection-wide allow entries, keep wizard-managed app profiles additive across binding precedence, and repair legacy over-grants with a data migration. Add decision-level regression coverage for generic and curated MCP paths. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandPaperclip	5634c2b966	fix(security): omit query strings from HTTP logs Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:02 +00:00
DottaandClaude Opus 5	f7023b205c	fix(security): consume and actor-bind OAuth state on a denied callback A denial or a cancel is a final answer to an authorization request, but `completeOAuthCallback` treated it as merely a failed callback: the row in `tool_oauth_states` survived, so the `state` the user just refused stayed completable for the rest of its 10-minute TTL by anyone who could produce a code. Any linked `request_confirmation` also stayed `pending`, so the board kept offering an authorization link for a flow the user had already declined and the requesting agent never learned the answer. Route every terminal callback — success, denial, cancel — through one `consumeOAuthState` helper. Two properties pull in opposite directions and both matter: - a stranger's callback must not consume the request, so the row is loaded and bound to the caller (expiry, actor type/id, session, or the subject user) before anything is deleted, and a failed binding check leaves the victim's flow live and completable; - a replayed callback must not complete the request, so the delete is the single statement that decides ownership — `DELETE … RETURNING` hands the row to exactly one of two concurrent callbacks and the loser is told the state is spent rather than exchanging a code against it. A denial then resolves any linked interaction as `rejected`, scoped to a still-`pending` row so a board user who answered the card directly keeps their own answer, with a Paperclip-authored reason rather than the provider's. The message and its `providerError` label are PAP-17108's, unchanged. Five regression tests, both negative-controlled: a code obtained before a denial can no longer be exchanged; an unrecognized cancel code behaves the same; another session's or another user's denial is refused without spending the request, which the owner then completes; the board's prompt ends `rejected`; and two simultaneous callbacks produce exactly one token exchange. That last one needs a second database handle — this driver pipelines everything issued through one handle, which serializes the two callbacks and makes a non-atomic delete pass — and it has to connect before racing, or the first callback wins uncontested. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:02 +00:00
DottaandClaude Opus 5	fc9f6619b1	fix(security): redact upstream OAuth provider errors instead of reflecting them A generic remote MCP connection points at an arbitrary authorization server, so `error`, `error_description`, `error_uri` and the response body are all attacker-chosen. Paperclip was returning the provider's `error_description` verbatim as the public error message on the callback-denial, token-exchange and dynamic-client-registration paths, and the callback did it before validating the state at all. A hostile provider could therefore plant a canary secret, ANSI escapes, or "paste your recovery key here" instructions into API responses, board UI copy, and 4xx log lines — in Paperclip's own voice. The operator now only ever reads text Paperclip authored: - `normalizeOAuthProviderError` reduces the provider's `error` to a bounded, allowlisted label (RFC 6749 §4.1.2.1/§5.2, RFC 7591 §3.2.2, OIDC Core §3.1.2.6). An unrecognized code collapses to `unrecognized` rather than being echoed, since the label is still untrusted input. - `oauthProviderErrorMessage` maps that label to stable Paperclip copy. The label plus the upstream HTTP status stay in structured `details` for diagnosis; the description and body are never read on any path. - `error_description` is gone from the callback route and from the `completeOAuthCallback` input type, so there is nothing left to reflect through, and `redactSensitive` scrubs it from the request query that `customProps` copies into 4xx log lines. - The callback validates the state binding and the actor before acting on a provider-reported failure, and consumes the state so a denial is terminal. Refresh goes through the same token-exchange path, and revocation makes no provider call, so both are covered. Tests plant a canary secret, ANSI escapes and markdown in `error_description` and assert none of it reaches an API response, a thrown message, a console line, an audit row or an activity detail; both assertions were negative-controlled by restoring the reflection. PAP-17108. Finding 3 of the PAP-17088 security review. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:02 +00:00
DottaandClaude Opus 5	0aaf6ddbea	fix(server): harden the pinned remote MCP transport's failure paths Pinning to `approved[0]` alone dropped the failover `fetch` gave a multi-homed host, so one dead A record took the whole connection down. Walk the approved addresses in resolution order instead — but only for addresses that are unreachable. A peer that answers from an unapproved address is the rebinding defence firing, not a reachability problem, so it still fails closed on the first try rather than being retried past. Also close the gaps the response deadline left behind: - a connect timeout used to leak the half-open socket, since nothing above that point owned it yet; - both deadlines threw bare `Error`s, so callers that switch on the guard's error codes saw a timeout as an unclassified failure — they now carry `remote_http_response_timeout`; - a finished response left an armed socket timer behind; and - the default deadline drops from undici's 300 s to 30 s, which is already generous for metadata discovery, a token exchange or a JSON-RPC round trip. `tools/call` owns a caller-set budget an operator can raise to 60 s, so it passes `responseTimeoutMs` explicitly rather than being truncated by the tighter default. Covers each with a regression test, including a peer that dribbles header bytes forever — the case that rules out `req.setTimeout`, whose idle clock such a peer can reset indefinitely. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:02 +00:00
DottaandClaude Opus 5	920fe47d35	fix(security): validate discovered OAuth endpoints before browser navigation A generic remote MCP connection lets the server it points at advertise its own authorization-server metadata, and `authorization_endpoint` was accepted as an arbitrary string: `startOAuth` built a `URL` from it and the board passed the result to `window.location.assign`. A hostile server could therefore advertise `javascript:`/`data:` to run script in the board's origin, `file:` to read a local path, or plain `http:`/a credential-bearing URL to downgrade or disguise where the operator was being sent. Parse every OAuth endpoint through one shared validator instead — discovered metadata, `WWW-Authenticate` hints, pasted/persisted config, and gallery defaults alike. It requires https (loopback http only under the existing local-development policy, plus this deployment's own origin, which is how the smoke-lab fixture is served), and rejects embedded credentials, fragments and malformed values. Discovery drops an unusable endpoint so a second advertised authorization server still gets a chance, and raises the refusal only if nothing safe was found — so an unsafe value is never persisted and never reported as a bare "does not advertise OAuth sign in". The token and registration endpoints go through the same gate, so a row written before this existed cannot send a code or client secret over plaintext. The board applies the same validator at the navigation boundary rather than trusting the response body, and — since a valid HTTPS page can still phish — names the authorization host on the redirect screen while keeping the "Unverified server" label. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:01 +00:00
Dotta	b2bf4599c3	fix(server): give the pinned remote MCP transport a response deadline The pinned transport replaced platform fetch, and with it undici's headersTimeout/bodyTimeout. Only the gateway tools/call path passes an AbortSignal; the OAuth discovery, registration and token-exchange callers pass none, so a remote server that accepted the connection and then stayed silent would hold the request open indefinitely. That is a hang the code this replaced did not have. Adds a 300s default matching undici, applied as a hard headers deadline (not req.setTimeout, which is socket-idle based and a dribbling server could reset forever) plus an idle deadline between body chunks so a half-sent body rejects in response.text() instead of hanging the caller. Both new tests hang to the vitest timeout when the deadlines are removed. Refs PAP-17098	2026-08-20 21:20:01 +00:00
Dotta	c281bd1705	fix(server): pin remote MCP egress to the approved address assertPublicRemoteHttpEndpoint resolved an operator-supplied hostname, approved it, and then handed the hostname to global fetch, which resolved it a second time. A name server the attacker controls can answer with a public address for the guard's lookup and a loopback, RFC 1918 or link-local address for the connection, so an authenticated public deployment could be walked onto internal services or cloud metadata. The guard now returns the address set it approved, and guardedRemoteHttpFetch dials that address itself: one resolution, no second lookup below it, the original hostname kept for Host, TLS SNI and certificate identity, and a peer-address check before a single request byte (or ClientHello) is written. Redirects stay manual so the caller re-runs the whole guard on every hop it follows. Wired into all three guard-then-fetch sites: OAuth discovery/registration/ token exchange, catalog tools/list, and the gateway tools/call path. Two cases keep platform fetch, both because there is nothing to pin: deployments that allow private endpoints, and URLs that already carry an IP literal. Regression coverage models the rebinding name server deterministically — public on the first answer, 127.0.0.1 after it — and proves the request lands on the approved address while the loopback listener sees no connection at all. Reintroducing either half of the fix (a second lookup at dial time, or dropping the peer check) turns those tests red. Residual risk unchanged: egress allowlisting and network policy are still recommended as defence in depth. Refs PAP-17098	2026-08-20 21:20:01 +00:00
DottaandClaude Opus 5	0d24cc8505	feat(apps): add agent-config help beside Paste a config An operator who only knows a tool's name has nothing to paste. Add a compact question-mark control that hands them a ready-made request for an agent: research the official docs, reply with one paste-ready `mcpServers` JSON object first, use placeholders for every credential, then explain how to get each one. The prompt is a constant in shared, deliberately not a template. Nothing about the company, the endpoint, the pasted config, or a secret can reach it, so "opening or copying help makes no connection or import request" holds by construction rather than by review — and a server test lifts the JSON example straight out of the prompt and runs the real preview parser on it, so the prompt and the parser cannot drift apart. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:01 +00:00
DottaandClaude Opus 5	0c2b2652ea	test(server): cover generic remote MCP connections with an OAuth fixture One in-process fetch fixture stands in for an MCP server plus its authorization server, so the whole generic path — discovery, registration, authorization, catalog, review, install, revoke — is deterministic and needs no network or vendor credentials. Every case deliberately connects by URL and never names a gallery app, and asserts the connection carries no `sourceTemplateKey`, so a regression that reintroduced a dependency on curated metadata would fail here. Covers public/bearer/custom-header endpoints, the four registration tiers and their preference order, RFC 8707 `resource` on authorize and token, RFC 8414 and OIDC-suffix discovery for a pathful issuer, `iss` acceptance and mismatch, re-registration on a moved callback, refusal to auto-re-register over an operator-supplied client, SSRF rejection, company isolation, secret redaction in config/refs/API readback, and a client metadata document with no tenant data. The manual-client binding test caught a real bug: a pasted client's callback was never stamped on first use, so its binding check would have accepted any callback forever. Fixed alongside. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:01 +00:00
DottaandClaude Opus 5	a98c363a92	feat(server): make remote MCP OAuth transport-generic and spec-current An unknown standards-compliant MCP endpoint could discover an OAuth challenge but never complete one: `ensureOAuthClient` only reached registration when a gallery `AppDefinition` method listed `ownershipModes: ["dcr"]`, so a URL-only connection died on "OAuth client id is not configured". Replace that gate with the registration preference the current MCP client-registration guidance recommends — a client the deployment preconfigured for the issuer, then a Client ID Metadata Document, then dynamic registration, then client credentials the operator preregistered — and allow a generic connection to register only after protected-resource/authorization-server discovery actually produced a metadata document. Client material is bound to issuer, MCP resource, callback URI and company, and re-registers when any of those move; a manually supplied client refuses to auto-re-register and asks the operator instead. Bring the broker in line with current guidance along the way: RFC 8707 `resource` on authorization, token and refresh requests; RFC 8414 and OIDC path-aware `.well-known` variants for pathful issuers, with the issuer in the document validated against the one used to build the URL; RFC 9207 `iss` validated on the callback when returned; `application_type: web` on DCR; and `authKind`/issuer/resource persisted so refresh, reconnect, revoke and diagnostics stop treating a generic connection as `authKind: none`. Header names and values from a pasted config are re-checked here, at the last point before they become real request headers. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-20 21:20:01 +00:00
DottaandPaperclip	860eb96c1e	feat(apps): simplify PostHog connection setup Default PostHog to broad tool access, move optional filters and response mode behind a reusable Advanced disclosure, and codify the connection UX rule in the bundled integration skill and playbook. Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:01 +00:00
DottaandPaperclip	7b816839c9	fix(apps): preserve scoped headers during tool calls Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:01 +00:00
DottaandPaperclip	ba4ff3fdf6	test(apps): cover PostHog gallery route Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:01 +00:00
DottaandPaperclip	b5301d3ab3	feat(apps): add governed PostHog connector Co-Authored-By: Paperclip <noreply@paperclip.ing>	2026-08-20 21:20:01 +00:00
David V Claude Opus 4.8 Paperclip Dotta Devin Foley	233c12f029	feat: add kimi-local adapter for Kimi Code CLI (CLI + ACP engines) (#9967 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Local agent adapters (`claude_local`, `gemini_local`, `grok_local`, …) are the integration surface that lets Paperclip run coding CLIs on the host machine > - The Kimi Code CLI (`kimi`, Moonshot AI) has a documented non-interactive mode, `kimi -p --output-format stream-json` with session resume via `kimi -r`, but Paperclip has no built-in adapter for it > - So Kimi users (especially Kimi membership / OAuth subscribers) cannot onboard their CLI to Paperclip agent teams > - This pull request adds a complete built-in `kimi_local` adapter (both execution engines, session management, instructions + skills delivery, thinking-effort control, environment test, UI and CLI modules, docs) following the established `gemini_local`/`grok_local` package pattern > - Kimi Code ships an ACP server (`kimi acp`), so the adapter runs on Paperclip's shared acpx engine by default (streaming transcript with live tool status, like `claude_local`/`gemini_local`) and falls back to a headless CLI lane (`kimi -p --output-format stream-json`) when ACP prerequisites are unavailable > - The benefit is that Kimi Code becomes a first-class Paperclip agent lane: selectable in the UI, resumable across heartbeats, with the same operating context (instruction bundle, skills, effort) and streaming transcript the other local adapters get ## Linked Issues or Issue Description - Supersedes #9880 (same branch; expanded from the CLI-only lane into a complete adapter with the default ACP engine lane, control-plane skill install, and live transcript wiring) - Refs #9879 (adapter request for Kimi Code CLI, filed with this PR) - Refs #163 (original Kimi support request) Duplicate/related prior PRs, per the dedup search (both appear stale: no updates or maintainer review since May 2026, and both target an older Kimi CLI interface; calling them out for reviewer context per CONTRIBUTING.md): - Refs #6276 (`feat: add kimi-local adapter`): targets an older array-based content format (`{type: think}`/`{type: text}` blocks), not the current documented stream-json schema - Refs #5202 (`feat(adapter): add Kimi CLI local adapter with Wire protocol support`): builds on a `--wire` JSON-RPC interface that current Kimi Code CLI (0.27.0) no longer documents; the current documented headless interface is `-p --output-format stream-json` This PR is a fresh implementation against current master and the currently documented/verified Kimi CLI behavior (see Verification). Happy to fold in anything useful from the earlier attempts if a reviewer prefers. ## What Changed - New adapter package `packages/adapters/kimi-local` (`@paperclipai/adapter-kimi-local`), modeled on `gemini-local`/`grok-local`: - `src/server/execute.ts`: spawns `kimi -p <prompt> --output-format stream-json` (argv array, no shell), `-m <model>` only when configured, `-r <sessionId>` when the stored session cwd matches the run cwd, automatic fresh-session retry on unrecoverable-session errors, headless-safe env (`CI=1`, `NO_COLOR=1`, `KIMI_CODE_NO_AUTO_UPDATE=1`, `TERM=dumb`; user-configured values win), full remote (ssh/sandbox) execution lane with runtime install via `@moonshot-ai/kimi-code` - Instruction bundle delivery: the prompt path directive now names the sibling instruction files (`./HEARTBEAT.md`, `./SOUL.md`, `./TOOLS.md`) alongside the prepended entry file, and local runs pass `--add-dir <instructions-dir>` so Kimi can actually open them (matching `claude_local`). Without this, only the entry file reached Kimi and agents improvised the operating workflow that `HEARTBEAT.md` documents - Thinking effort: a configured `effort` is forwarded as the `KIMI_MODEL_THINKING_EFFORT` operational override (Kimi has no per-invocation effort flag). It is only sent for models that advertise `support_efforts` (currently `kimi-code/k3`) to avoid provider rejections, and `medium` maps to `high` since Kimi has no medium tier (`low`/`high`/`max` pass through) - Skills delivery: desired Paperclip skills are delivered via Kimi's `--skills-dir` flag from a dedicated per-run directory (a local snapshot, or the synced snapshot on remote targets), so skills load reliably and in isolation. Paperclip never overwrites the shared `$KIMI_CODE_HOME/skills` home, so skills installed by the operator or other agents are left intact. `--skills-dir` is only passed when at least one skill is desired, so unconfigured agents keep Kimi's default skill discovery - Live run status: the adapter now forwards each streamed stream-json line to `onEvent` (assistant `content` as an assistant snippet, `tool_calls` as tool-name events), which drives the issue-thread activity indicator (`currentToolName` / `lastAssistantSnippet` / `lastEventAt`). Previously the adapter only wrote the raw run log, so the issue thread showed a stale "no output for N s" line with no tool or reasoning context while Kimi worked. Tool results are omitted so the last meaningful "Using X" / snippet is not overwritten by a generic label - `src/server/parse.ts`: parses the verified Kimi stream-json event shapes (`assistant` text, `assistant.tool_calls` with JSON-string arguments, `tool` results, trailing `meta.session.resume_hint` for session-id capture) plus failure classifiers (`kimi_auth_required`, transient network, unrecoverable session). A signaled exit (null exit code, not a timeout) is now reported as a failure rather than coalesced to success, and the error message names the terminating signal - `src/server/skills.ts`: lists/syncs Paperclip skills for the adapter's skill-management surface - `src/server/test.ts`: environment test covering CLI resolution + `kimi --version`, cwd check, auth detection (OAuth credential dirs, keyed `[providers.]` in config.toml, or the `KIMI_MODEL_NAME` + `KIMI_MODEL_API_KEY` env pair), and a live hello probe - `src/ui/` (stdout-line parser for transcripts, config builder) and `src/cli/` (stream event formatter) modules - Root metadata: three managed model aliases (`kimi-code/kimi-for-coding`, `kimi-code/kimi-for-coding-highspeed`, `kimi-code/k3`), effort-capable-model metadata (`EFFORT_CAPABLE_MODELS`, effort mapping helpers), `agentConfigurationDoc` - Tests: 101 tests across parse, execute (args building, resume gating, retry, auth error code, timeout, signaled-exit failure, effort forwarding/gating/mapping, `--add-dir` instructions directive, `--skills-dir` gating, `onEvent` runtime-event forwarding), ACP engine (engine resolution, acpx config build, node-version gate), ACP transcript delegation, environment test, UI parse/build-config - ACP engine lane (default)* (`src/server/acp.ts` + shared `adapter-utils/acpx-engine`): Kimi Code ships an ACP server (`kimi acp`), so `kimi_local` now runs on Paperclip's shared acpx engine by default, matching `claude_local`/`codex_local`/`gemini_local`. The issue-thread transcript streams live (assistant text deltas, tool calls with a `pending`->`completed` status lifecycle) instead of the CLI lane's bursty complete-message output. Registered `kimi_local -> "kimi"` in `ACPX_ADAPTER_AGENT_IDS` and resolved the built-in agent command to `kimi acp`; `execute.ts` dispatches to the ACP executor first with an automatic CLI fallback when ACP prerequisites fail (`engine=acp` requires ACP, `engine=cli` pins the headless lane); `index.ts` falls back to the shared acpx session codec; the UI/CLI delegate `acpx.` events to the shared acpx transcript parser and event formatter. The headless CLI lane (above) remains as the fallback - Registration* (one entry each, mirroring existing adapters): server adapter registry + `BUILTIN_ADAPTER_TYPES`, `AGENT_ADAPTER_TYPES` (shared), UI adapter registry + display registry (`Kimi Code`, Moon icon) + capabilities defaults, CLI adapter registry, `Dockerfile` (package copy + `npm install --global @moonshot-ai/kimi-code@latest`), `vitest.config.ts` workspace, `scripts/release-package-manifest.json` - Behavioral sets mirroring `gemini_local` (Kimi resumes sessions the same way): `GIT_SENSITIVE_LOCAL_ADAPTER_TYPES`, `SESSIONED_LOCAL_ADAPTERS` (heartbeat + recovery), `REMOTE_MANAGED_ADAPTERS`, ssh/sandbox execution-target allow-lists, `ADAPTER_DEFAULT_RULES_BY_TYPE` (`timeoutSec: 0`, `graceSec: 15`), and `LEGACY_SESSIONED_ADAPTER_TYPES` + `ADAPTER_SESSION_MANAGEMENT` in adapter-utils - UI touch-points: New Agent default-model branch, AgentConfigForm command map (`kimi_local: "kimi"`) + model defaults + a Kimi-specific thinking-effort option list (`Low`/`High`/`Max`, reflecting Kimi's tiers rather than borrowing Claude's), OnboardingWizard (command map, model default, `kimi login` / `KIMI_MODEL_NAME + KIMI_MODEL_API_KEY` auth hints, manual-debug command line), InviteLanding enabled adapters - Control-plane skill install (`cli/src/commands/client/agent.ts`): `paperclipai agent local-cli` seeded the Paperclip control-plane skills into `~/.codex/skills` and `~/.claude/skills` so Codex/Claude agents auto-discover the API reference every run. Kimi had no equivalent target, so `kimi_local` agents began each session without the control-plane skill and rediscovered routes (e.g. the company-scoped `POST /api/companies/{companyId}/issues`) by trial and error. Added `~/.kimi-code/skills` (honoring `KIMI_CODE_HOME`) as a third install target for parity. Independent of the per-run `--skills-dir` delivery, which only applies to explicitly configured skills. - Docs: `docs/adapters/kimi-local.md` (prerequisites, auth options, config fields including `effort`, session resume, instruction bundle, skills delivery, control-plane skill install) + a row in `docs/adapters/overview.md` Out of scope (deliberately): model profiles, built-in agent `allowedAdapterTypes` additions. ## Verification\n\nCurrent-master rebase verification (OpenAI Codex, 2026-08-03): 13 focused files / 231 tests pass; adapter-utils, server, UI, CLI, and Kimi adapter typechecks pass; full repository build and UI token gates pass. The branch is conflict-free against master at head `1249df117c5e12e5771b9a570a6340866450619e`.\n\nAutomated (all from repo root, pnpm 9.15.4, Node 22): - `vitest run packages/adapters/kimi-local`: 89/89 pass (includes coverage for the instruction `--add-dir` directive, effort forwarding/gating/mapping, `--skills-dir` gating, the signaled-exit failure path, and `onEvent` runtime-event forwarding with cross-chunk line buffering) - `vitest run server/src/__tests__/adapter-registry.test.ts server/src/__tests__/adapter-routes.test.ts server/src/services/heartbeat-stop-metadata.test.ts ui/src/adapters/adapter-display-registry.test.ts`: 37/37 pass - `vitest run cli/src/__tests__/skills.test.ts`: 13/13 pass (the control-plane skill install target follows the existing Codex/Claude install path, whose symlink logic is unchanged) - `vitest run packages/shared`: 307/307 pass; `vitest run packages/adapter-utils`: pass except one pre-existing, unrelated failure (`mcp-isolation.integration.test.ts` requires Claude CLI ≥ 2.1.207; host has 2.1.185, fails identically on unmodified master) - `pnpm --filter @paperclipai/adapter-kimi-local typecheck\|build`, plus typecheck of `server`, `ui`, `cli`, `adapter-utils`: all clean - `pnpm install --frozen-lockfile`: passes (the PR diff itself contains no lockfile changes, per repo policy; verified against a locally regenerated lockfile) - `node scripts/check-no-git-push.mjs` and `node scripts/check-forbidden-tokens.mjs`: pass - CI note: the `policy` job's release-bootstrap step is expected to stay red until a maintainer bootstraps the first npm publish of `@paperclipai/adapter-kimi-local`; see the CI Note for Maintainers comment. All other contributor-actionable checks are green. Manual end-to-end (real Kimi CLI 0.27.0, OAuth login, dev server on an isolated instance): 1. Server `GET /api/adapters` lists `kimi_local` as builtin with correct capability flags; models endpoint returns the three Kimi models 2. `POST .../adapters/kimi_local/test-environment`: all checks pass, including a live `kimi -p` hello probe 3. Created a `kimi_local` agent and invoked two heartbeats: run 1 spawned `kimi -p ... --output-format stream-json`, Kimi used its `Read` tool, produced the expected answer, and the session id was captured from the `session.resume_hint` meta event; run 2 resumed the same Kimi session (`sessionIdBefore == sessionIdAfter`) via `-r` 4. UI: adapter appears in the New Agent dropdown; selecting it shows the Kimi command placeholder, the three models, and the Kimi config fields; the run transcript renders Kimi tool calls via the adapter's stdout parser The instruction-bundle, thinking-effort, and `--skills-dir` changes landed after the manual run above. They are covered by the unit tests listed under Automated, and the Kimi CLI flags they rely on (`--add-dir`, `--skills-dir`, `KIMI_MODEL_THINKING_EFFORT`) were confirmed against the installed Kimi Code CLI 0.27.0 (`kimi --help`, config-file thinking-effort docs). Screenshots (assets branch on the fork, not part of the diff): ![Kimi Code in the Add a new agent runtime picker](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/00-kimicode.png) ![Adapter dropdown with Kimi Code](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/01-adapter-dropdown-kimi.png) ![Kimi adapter selected: command, model, config fields](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/02-kimi-adapter-selected.png) ![Kimi models in the model dropdown](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/03-kimi-model-dropdown.png) ![Successful resumed heartbeat run (kimi_local invocation + parsed transcript)](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/04-successful-resumed-run.png) ![Agents list showing the Kimi Code label](https://raw.githubusercontent.com/hawikk/paperclip/assets/kimi-local-pr-screenshots/shots/05-agents-list.png) ## Risks - Low risk to existing behavior: the change is additive, one new workspace package plus single-entry registrations alongside existing adapters; no existing adapter code paths are modified. - The adapter invokes the locally installed `kimi` CLI; like other local adapters, run behavior depends on the host's Kimi version. The parser is written against the documented/verified 0.27.0 stream-json schema and degrades gracefully (malformed lines are skipped, failures surface as run errors). - `--skills-dir` overrides Kimi's auto-discovery of user and project skills for the run. This is intentional (paperclip-managed agents get a reproducible, isolated skill set), and it is only passed when at least one Paperclip skill is desired, so unconfigured agents keep default discovery. - Thinking effort is only forwarded to models that advertise `support_efforts` (currently `kimi-code/k3`); `EFFORT_CAPABLE_MODELS` must be extended when more Kimi models gain support, otherwise a configured effort is silently ignored for them. - `Dockerfile` now installs `@moonshot-ai/kimi-code@latest` globally alongside the other agent CLIs, so image size increases slightly. - Maintainer action needed for the npm bootstrap gate: the `policy` job's release-bootstrap step fails until the first npm publish of `@paperclipai/adapter-kimi-local` (the gate from #5146 that every new adapter package has passed through). Enrollment with `publishFromCi: true` is required by the manifest validator (dropping the entry, `false`, or `private` are all rejected), so this is intentionally left to a maintainer. Remaining CI lanes are expected to run once it is done. ## Model Used\n\n- Current-master rebase, conflict adaptation, and registry-parity coverage: OpenAI, GPT-5 Codex (Codex agent; exact serving model ID and context-window size were not exposed to the runtime), with repository, shell, Git, and GitHub tooling. It preserved Hawik’s commit authorship, reconciled ACPX and environment-capability changes, added current registry tests, and ran the verification above.\n- Adapter implementation and initial review: Moonshot AI, Kimi K3 Coding (latest), via Kimi Code CLI v0.27.0 (`kimi-code/k3` alias, 1M-token context window, thinking mode, agentic tool use). The CLI agent explored the repo, wrote the adapter implementation (delegated to a coder sub-agent of the same model), ran tests, and drafted the first version of this PR body. A second model-driven review pass (read-only, same model) audited the diff for security/correctness before submission; its findings (shell-quoting hardening, auth-detection false positive, session-compaction registration, test gaps) were fixed and are included. - Harness-context fixes and review responses: Anthropic, Claude Opus 4.8 (`claude-opus-4-8`) via Claude Code. Diagnosed from run logs that Kimi received only the entry instructions file (not the `HEARTBEAT.md`/`SOUL.md`/`TOOLS.md` bundle) and that `effort` was never wired, then implemented the instruction `--add-dir` delivery, `KIMI_MODEL_THINKING_EFFORT` forwarding, and `--skills-dir` skill delivery, added the accompanying tests and docs, and addressed the automated review comments (preserving external skills on remote sync, treating a signaled exit as a failure). Also extended the `paperclipai agent local-cli` installer to seed the control-plane skills into `~/.kimi-code/skills` for Codex/Claude parity, wired `onEvent` runtime events so the issue-thread activity indicator reflects Kimi's tool and reasoning output live, and built the ACP engine lane (`kimi acp` via the shared acpx engine, default) so the transcript streams with live tool status like the other ACP adapters. The Kimi CLI flags, subcommand, and env var relied on here were verified against the installed Kimi Code CLI 0.27.0. - All CLI behaviors claimed here (`-p`, `--output-format stream-json`, `-r` resume, event shapes, `--add-dir`, `--skills-dir`, `KIMI_MODEL_THINKING_EFFORT`) were verified empirically against the installed Kimi CLI, not assumed. ## 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 (only the release-bootstrap step remains red, pending the maintainer npm publish described in Risks) - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups (will address all Greptile comments as they arrive) - [x] I will address all Greptile and reviewer comments before requesting merge --- ## Maintainer Addendum (2026-08-20) The shared acpx-engine and issue-chat changes (run-summary segmentation, placeholder tool-event coalescing, `ISSUE_CHAT_TRANSCRIPT_MAX_VISIBLE_ENTRIES` 30 → 400, live-reasoning UI) have been extracted to #11761 so the cross-adapter behavior changes review and revert independently — both commits there preserve @hawikk's authorship. This PR is now the kimi-specific adapter only (60 files, +3,793/−8, essentially pure addition); the only shared-engine touch left is the `kimi acp` command resolution. `publishFromCi` is `true` — the package name is bootstrapped on npm. --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Paperclip <noreply@paperclip.ing> Co-authored-by: Dotta <bippadotta@protonmail.com> Co-authored-by: Devin Foley <devin@paperclip.ing>	2026-08-20 12:06:33 -07:00
Nicky LeachandPaperclip	b83e14ad2c	fix(runtime): stop the readiness probe from stealing the guest exposure port (#11788 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The workspace runtime starts guest processes and exposes their ports. > - The readiness wait bound the guest port to test whether it was ready. > - That bind could take the port before the guest process used it. > - This pull request reads listener state without a competing bind and recovers from a real port collision. > - The benefit is stable runtime exposure and a clear recovery path for a genuine collision. ## Linked Issues or Issue Description What happened? The managed HTTPS exposure test failed intermittently with `listen EADDRINUSE` on `127.0.0.1:42000`. The readiness wait bound the guest port before the guest process could bind it. Expected behavior The readiness wait must not hold the guest port. The runtime must recover when an external process owns the assigned port. Steps to reproduce 1. Run `npx vitest run server/src/services/workspace-runtime-exposure.test.ts` from the repository root. 2. Inject a delayed guest bind and a widened readiness-probe hold. 3. Observe the port collision before this fix and the successful retry after this fix. Paperclip version or commit `b375bbd913cb2edc8e077f4339ce0745e53bd462` Deployment mode Built from source with the server test suite. Installation method Built from source with pnpm. Agent adapter(s) involved Not adapter-specific. This is a core runtime test. Database mode Not database-related. Relevant logs or output Before this fix, the test reported `listen EADDRINUSE: address already in use 127.0.0.1:42000`. ## What Changed - Read listener presence from `/proc` on Linux instead of binding the guest port. - Keep the bind probe as the fallback on non-Linux hosts. - Capture the current port owner when an exposed guest exits with `EADDRINUSE`. - Quarantine the app and HMR pair, then allocate the next free port pair within the existing range. - Add a deterministic regression test for quarantine, re-allocation, and self-diagnosis logging. ## Verification - Run `npx vitest run server/src/services/workspace-runtime-exposure.test.ts` from the repository root. - The target suite passes 19 tests locally. - The related runtime suites pass 105, 128, and 21 tests locally. - Run `tsc -p server/tsconfig.json` to check the changed server files. - CI must pass the general server shard and all required checks. - Greptile must report 5/5 with no open P2 comments, recommendations, or follow-ups. ## Risks The Linux readiness path now depends on `/proc` listener data. Non-Linux hosts retain the existing bind-probe fallback. The port range and allocation limit do not change. ## Model Used OpenAI GPT-5. This agent used tool calls for repository checks and GitHub PR management. Priya Raman authored the code change. ## 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>	2026-08-20 12:05:35 -07:00
Devin Foley	933749e01f	test(server): deflake postgres teardown and pinned exposure port (#11667 ) ## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The server test suite gates every merge and every release cut. > - Three server tests each failed exactly once on markdown-only or unrelated diffs, then passed on rerun. > - One of the three (the git-operation-scheduler owner/joiner race) was fixed on master independently by [#11671](https://github.com/paperclipai/paperclip/pull/11671) while this PR was open, so after rebasing this pull request carries the remaining two. > - A flaky gate makes release operators rerun CI and stop trusting red results. > - Each remaining flake has a real nondeterminism: a teardown race and a hard-coded host port. > - This pull request removes the nondeterminism from the two tests without weakening what they prove. > - The benefit is a test gate that fails only when the product is broken. ## Linked Issues or Issue Description - [x] I searched open and closed issues and pull requests for these test files and for these failures. I found no duplicate report or fix. What happened? Three one-off CI failures occurred during release operations, each on a diff that could not have caused it, and each passed on rerun: 1. Run [32086355930](https://github.com/paperclipai/paperclip/actions/runs/32086355930): `server/src/__tests__/interaction-resolution-cross-issue-cap-postgres.test.ts` — all 7 tests passed, but vitest recorded an Unhandled Error and failed the run: `TypeError: Cannot read properties of null (reading 'write')` at `postgres@3.4.9/src/connection.js:255 Immediate.nextWrite`. 2. Run [32096743814](https://github.com/paperclipai/paperclip/actions/runs/32096743814): `server/src/services/workspace-git-operation-scheduler.test.ts` — the test "coalesces the same canonical key and cleans single-flight state after success and failure" failed with an AssertionError: the two concurrent calls came back with the `singleFlightJoined` values swapped. (Fixed on master by [#11671](https://github.com/paperclipai/paperclip/pull/11671) with an equivalent single-flight barrier while this PR was open; the fix was dropped from this PR on rebase and the file is no longer touched here.) 3. Run [32196201529](https://github.com/paperclipai/paperclip/actions/runs/32196201529): `server/src/services/workspace-runtime-exposure.test.ts` — the test "keeps an existing runtime port that is already inside the dedicated range" failed once out of 610 recorded runs because the runtime came back on a relocated port instead of the pinned 42500. Expected behavior The tests pass on every run when the code under test is correct. A red result means a product defect, not scheduling luck on the CI host. Steps to reproduce Each flake is a low-probability race, but both remaining mechanisms reproduce deterministically: 1. Postgres teardown: the suite never ends the postgres.js pool behind `createDb`; `afterAll` only stops the embedded server. postgres.js batches small writes and flushes them with `setImmediate` (`connection.js` `nextWrite`), and `close()` nulls the socket. Stop the server while the pool is open and a pending flush can run after the socket is gone. 2. Exposure pinned port: hold any loopback socket on 42500 or 52500 (both are inside the default Linux ephemeral port range, 32768–60999) and run the test. The allocator correctly relocates, and the assertion fails with `expected 42000 to be 42500`. The client side of any loopback connection on the CI host can land on those ports. Paperclip version or commit Branched from `master` at `4b968d8c0`; rebased onto `5a1ce7aed`. Privacy checklist I reviewed this description and removed private instance URLs, internal task identifiers, credentials, and user paths. ## What Changed Both fixes are test-side. I found no product race. - `interaction-resolution-cross-issue-cap-postgres.test.ts`: `afterAll` now ends the drizzle/postgres.js pool (`db.$client.end()`) before it stops the embedded Postgres server. `end()` waits for in-flight queries, including a fire-and-forget wake that lands just after a response, and closes the sockets from the client side first. Sibling suites (for example `heartbeat-plugin-environment.test.ts`) already use this order; this suite had skipped the pool shutdown. - `workspace-runtime-exposure.test.ts`: the pinned-port test no longer hard-codes 42500. It scans the dedicated range with the suite's real loopback probe, finds the lowest free app/HMR pair, then pins the next free pair strictly above it. If the keep-preferred-port path broke, the ascending fallback scan would return the lower pair, so the assertion keeps its discriminating power while no longer betting on one fixed host port staying free. - (Dropped on rebase: the `workspace-git-operation-scheduler.test.ts` coalescing fix, superseded by the equivalent barrier merged in [#11671](https://github.com/paperclipai/paperclip/pull/11671).) ## Verification - Reproduced the exposure flake exactly: with a listener held on `127.0.0.1:52500`, the pre-fix test fails with `expected 42000 to be 42500`; the fixed test passes with the port still held. - The postgres flake is a probabilistic teardown race and I could not trigger it on demand. The mechanism is established from `postgres@3.4.9` source (`setImmediate`-batched `nextWrite` versus `close()` nulling the socket) and the fix removes the whole class by closing the pool before the server. - Repeat runs after the fix: the pinned-port exposure test 20/20 green while the Postgres suite looped concurrently for loopback churn; `interaction-resolution-cross-issue-cap-postgres.test.ts` 15/15 green with no unhandled errors. - Re-verified after rebasing onto `5a1ce7aed`: both changed test files pass and `tsc --noEmit` passes in `server/`. - Environment note: three unrelated tests in `workspace-runtime-exposure.test.ts` (the wildcard-bind diagnosis tests) fail on macOS before and after this change because they read `/proc`; they are untouched and pass on Linux CI. ## Risks - Low risk: both changes are test-only; no product code changed. - The pinned-port test keeps a tiny time-of-check/time-of-use window between its own probe and the runtime's bind. The window shrinks from "one fixed port must stay free across the whole CI fleet" to milliseconds on a pair just verified free. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used Claude Fable 5 (Claude Code) — model ID `claude-fable-5`, with repository tools and local code execution for reproduction and repeat-run verification. ## 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	2026-08-20 11:27:39 -07:00
dependabot[bot]Priya Raman Paperclip	54b8bec444	build(deps): bump pino-http from 10.5.0 to 11.0.0 (#11716 ) Bumps [pino-http](https://github.com/pinojs/pino-http) from 10.5.0 to 11.0.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/pinojs/pino-http/releases">pino-http's releases</a>.</em></p> <blockquote> <h2>v11.0.0</h2> <h2>What's Changed</h2> <ul> <li>build(deps-dev): bump <code>@types/node</code> from 22.15.32 to 24.0.3 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/pinojs/pino-http/pull/370">pinojs/pino-http#370</a></li> <li>build(deps-dev): bump typescript from 5.8.3 to 5.9.2 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/pinojs/pino-http/pull/373">pinojs/pino-http#373</a></li> <li>build(deps-dev): bump tsd from 0.32.0 to 0.33.0 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/pinojs/pino-http/pull/376">pinojs/pino-http#376</a></li> <li>build(deps): bump actions/checkout from 4 to 5 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/pinojs/pino-http/pull/380">pinojs/pino-http#380</a></li> <li>build(deps): bump actions/setup-node from 4 to 5 by <a href="https://github.com/dependabot"><code>@dependabot</code></a>[bot] in <a href="https://redirect.github.com/pinojs/pino-http/pull/382">pinojs/pino-http#382</a></li> <li>Update for pino@10 by <a href="https://github.com/jsumners"><code>@jsumners</code></a> in <a href="https://redirect.github.com/pinojs/pino-http/pull/383">pinojs/pino-http#383</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/pinojs/pino-http/compare/v10.5.0...v11.0.0">https://github.com/pinojs/pino-http/compare/v10.5.0...v11.0.0</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/pinojs/pino-http/commit/6615953a8bfebf37c26e6438568724a091f80a82"><code>6615953</code></a> v11.0.0</li> <li><a href="https://github.com/pinojs/pino-http/commit/da0442ea7306b0560eada975391d13853c72b119"><code>da0442e</code></a> Update for pino@10 (<a href="https://redirect.github.com/pinojs/pino-http/issues/383">#383</a>)</li> <li><a href="https://github.com/pinojs/pino-http/commit/c77bf2546d44dbe7381264955ae97ca76ff302e1"><code>c77bf25</code></a> build(deps): bump actions/setup-node from 4 to 5 (<a href="https://redirect.github.com/pinojs/pino-http/issues/382">#382</a>)</li> <li><a href="https://github.com/pinojs/pino-http/commit/5b06a223d3ad15f97b1e0f68416410776c47fdde"><code>5b06a22</code></a> build(deps): bump actions/checkout from 4 to 5 (<a href="https://redirect.github.com/pinojs/pino-http/issues/380">#380</a>)</li> <li><a href="https://github.com/pinojs/pino-http/commit/bc69ee95e184f882570c7a9d551288b5b077fe02"><code>bc69ee9</code></a> build(deps-dev): bump tsd from 0.32.0 to 0.33.0 (<a href="https://redirect.github.com/pinojs/pino-http/issues/376">#376</a>)</li> <li><a href="https://github.com/pinojs/pino-http/commit/c2ccdb31d8961033c976686102f7d6279f97a1c2"><code>c2ccdb3</code></a> build(deps-dev): bump typescript from 5.8.3 to 5.9.2 (<a href="https://redirect.github.com/pinojs/pino-http/issues/373">#373</a>)</li> <li><a href="https://github.com/pinojs/pino-http/commit/6dbe316bd5d8860a3efbc963e5b6fed7a4b45384"><code>6dbe316</code></a> build(deps-dev): bump <code>@types/node</code> from 22.15.32 to 24.0.3 (<a href="https://redirect.github.com/pinojs/pino-http/issues/370">#370</a>)</li> <li>See full diff in <a href="https://github.com/pinojs/pino-http/compare/v10.5.0...v11.0.0">compare view</a></li> </ul> </details> <br /> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Priya Raman <priya@paperclip.ing> Co-authored-by: Paperclip <noreply@paperclip.ing>	2026-08-20 10:51:54 -07:00

1 2 3 4 5 ...