Skip to content

fix: preserve explicit runtime API URL - #11100

Open
Oldrich333 wants to merge 1 commit into
paperclipai:masterfrom
Oldrich333:fix/runtime-api-url-override
Open

fix: preserve explicit runtime API URL#11100
Oldrich333 wants to merge 1 commit into
paperclipai:masterfrom
Oldrich333:fix/runtime-api-url-override

Conversation

@Oldrich333

@Oldrich333 Oldrich333 commented Aug 8, 2026

Copy link
Copy Markdown

Thinking Path

  • Paperclip is the open source control plane for AI agents.
  • Managed remote runtimes use a host-side bridge to call the Paperclip API.
  • Public deployments can use a public URL that the server container cannot reach.
  • Paperclip already defines a separate runtime API URL for internal calls.
  • Server startup overwrote an explicit runtime URL with the public URL.
  • This pull request preserves the explicit runtime URL and keeps the public URL separate.
  • The benefit is reliable managed runtime bridges in container and reverse-proxy deployments.

Linked Issues or Issue Description

What happened?

Server startup replaced an explicit PAPERCLIP_RUNTIME_API_URL with the auto-derived public authentication URL. A host-side managed runtime bridge then called the public URL. The call failed when the Paperclip server container could not resolve or reach its own public hostname.

Expected behavior

Paperclip must preserve an explicit internal runtime URL. PAPERCLIP_API_URL must remain available as the separate public URL.

Steps to reproduce

  1. Configure an authenticated deployment with a public authentication base URL.
  2. Set PAPERCLIP_RUNTIME_API_URL to an internal URL that the server can reach.
  3. Start Paperclip.
  4. Observe that server startup replaces the internal value with the public URL.
  5. Start a managed remote runtime and observe that its callback bridge cannot reach the API.

Paperclip version or commit

19be4cf9278b70bc151063778a94bf38bfd5c903

Deployment mode

Authenticated self-hosted Docker deployment.

What Changed

  • Preserve an explicit PAPERCLIP_RUNTIME_API_URL during server startup.
  • Put the explicit runtime URL first in the runtime API candidate list.
  • Add a startup regression test for separate public and internal URLs.
  • Document the runtime URL and its precedence.

Verification

  • pnpm exec vitest run server/src/__tests__/server-startup-feedback-export.test.ts
  • pnpm --filter @paperclipai/server typecheck
  • The targeted test file passes all 17 tests.

Risks

  • Low risk. The behavior changes only when an operator explicitly sets PAPERCLIP_RUNTIME_API_URL.
  • Deployments without the variable keep the current auto-derived behavior.

Model Used

  • OpenAI Codex gpt-5.6-sol with medium reasoning, tool use, and code execution.
  • Google Gemini gemini-3-pro-preview performed an independent code review.

Checklist

  • I have included a thinking path that traces from project context to this change
  • I have specified the model used (with version and capability details)
  • I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work
  • I have searched GitHub for duplicate or related PRs and linked them above
  • I have either (a) linked existing issues with Fixes: # / Closes # / Refs # OR (b) described the issue in-PR following the relevant issue template
  • I have not referenced internal/instance-local Paperclip issues or links (only public GitHub #NNN / github.com/paperclipai/paperclip URLs)
  • My branch name describes the change (e.g. docs/..., fix/...) and contains no internal Paperclip ticket id or instance-derived details
  • I have run tests locally and they pass
  • I have added or updated tests where applicable
  • I have updated relevant documentation to reflect my changes
  • 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant