ctx7 login now always uses the device-code flow. The localhost-callback path is removed — every install (laptop, SSH, Codespace, Docker, CI) goes through the same boxed prompt and verification page. Drops the --device flag (it was the opt-in for what's now the default). Older CLI versions (≤ 0.5.0) continue to work against the unchanged auth endpoints, so pinned installs are unaffected.5a180d5: Add OAuth 2.0 device authorization flow (RFC 8628) for ctx7 login and ctx7 setup. Required for headless / remote hosts (SSH, Codespaces, Docker, CI) where the existing localhost-callback flow can't work — the browser was opening on the user's laptop while the callback listener ran on the remote host.
The new flow prints a verification URL and short code, then polls a token endpoint. The user visits the URL on any device, signs in, and approves; the CLI receives the same ctx7sk-… API key it would have gotten from the legacy flow. Device flow is selected automatically when SSH_CONNECTION is set or $DISPLAY is missing on Linux, and can be forced with ctx7 login --device. Polling tolerates transient network errors and 5xx responses without ending the session.
ctx7 setup now properly supports --antigravity, installing skills to .agent/skills, a GEMINI.md rule section (Antigravity reads Gemini-family config), and MCP config to Antigravity 2.0's documented global path ~/.gemini/config/mcp_config.json (with httpUrl for HTTP, matching the Gemini convention). Antigravity has no documented project-level MCP file, so setup --antigravity --project --mcp writes to the global location. Also removes the --universal flag from setup, which was advertised but silently ignored — it never propagated through agent selection, so passing it (e.g. setup --cli --universal --project) caused setup to fall back to auto-detection and write to the wrong directory.ctx7 setup --api-key <KEY> (without --cli, --mcp, or -y) now prompts to choose between MCP server and CLI + Skills modes. Previously, passing --api-key short-circuited to MCP, locking users out of the CLI + Skills option even though that mode also accepts an API key. Explicit --mcp / --cli / --stdio / --oauth / -y still skip the prompt as before.tenantId, audience, requiredScope) from the Context7 app, and verifies the token against the matching tenant's JWKS, enforcing the required scope claim when configured. User resolution happens downstream in the Context7 app against a pre-provisioned user mapping table — the MCP server only validates. Per-tenant JWKS cache and a 5-minute in-memory config cache keyed by JWT audience reduce overhead under load.resolve-library-id and query-docs tools, ships the context7-docs skill, and exposes a /c7-docs slash command. Wire format, error messages, and tool descriptions are copied verbatim from @upstash/context7-mcp so pi and MCP clients give the LLM identical instructions and output. Self-contained — no Context7 runtime dependencies. Works out of the box at IP-based rate limits; set CONTEXT7_API_KEY for the higher tier. Install with pi install npm:@upstash/context7-pi.X-Context7-Auth-Prompt: 1 response header on /v2/libs/search or /v2/context) that an anonymous client has crossed the per-IP threshold, the MCP server appends a one-time sign-in invitation to the tool result.
npx ctx7 setup --<client> --mcp -y (with --stdio appended when the MCP server is running on stdio) after explicit user confirmation. The CLI handles OAuth and writes credentials into the MCP client's config; the user restarts their MCP server / editor to pick up the new credentials.X-Context7-Client-IDE / User-Agent and selects the matching CLI flag (--cursor, --claude, --codex, --opencode, --gemini); falls back to interactive setup when unknown.Metrics per Queue/Flow-Control/Url are requested time to time but not implemented since they are basically expensive.
They are expensive because number of queues/flow-controls/url's can grow big.
One option is to let people configure a limited amount and keep statistics only for them.
Opened a generic issue but it would be great to get feedback on specific needs and use-cases in the comments.
We currently provide JS/TS and Golang SDKs that exposes the official trigger() method to start a new workflow run. To support a broader range of use cases, we plan to introduce a REST API endpoint that allows workflows to be started via a simple HTTP call. This will enable developers to trigger workflow runs from environments where our official SDK is not available.
A draft version of the API is as follows:
-H "Authorization: Bearer "">curl -X POST https://qstash.upstash.io/v2/workflows/trigger/WORKFLOW_URL>
-H "Authorization: Bearer "
It will be possible to pass configuration options (retries, flow-control) as HTTP headers when calling this endpoint.
Currently, the workaround is to call the workflow endpoint directly. However, this approach is not safe. If the workflow endpoint is temporarily unreachable, the request will fail without retries since it bypasses Upstash Workflow's delivery system for trigger request.
Docs can be found here https://upstash.com/docs/workflow/api-reference/runs/trigger-workflow-run
Currently, the Logs tab does not show details about the distribution or count of matching logs entries.
This makes it difficult to understand how often a specific filter matches. With recent improvements to our logging system, we can now add a histogram view for filter matches in the Logs tab. This will help users see how frequently events occur and view the total number of matches over a selected time range.
Below is a visual example of what we plan to introduce (AI-generated; the final design may differ):
Currently, the Logs tab does not show details about the distribution or count of matching logs entries. This makes it difficult to understand how often a specific filter matches.
With recent improvements to our logging system, we can now add a histogram view for filter matches in the Logs tab. This will help users see how frequently events occur and view the total number of matches over a selected time range.
Below is a visual example of what we plan to introduce (AI-generated; the final design may differ):
McpServer per HTTP request. Sharing one across requests let any concurrent transport.close clear the shared Protocol._transport, which broke sendNotification for in-flight long-running tool calls.query-docs MCP tool no longer accepts or forwards a researchMode parameter, and the CLI no longer exposes a --research flag on ctx7 docs.fetch timeouts. Switching enableJsonResponse to false makes the SDK return the HTTP response synchronously after request validation, so headers are sent in milliseconds instead of being buffered until the tool completes. This fixes clients that cap the underlying fetch waiting for headers (e.g., Claude Code's 60s wrapFetchWithTimeout).researchMode parameter from the query-docs tool's input schema. The underlying API still supports research mode, but several MCP clients hit per-request timeouts (60s defaults) on long-running research calls in ways that can't always be solved server-side. Hiding the parameter prevents agents from invoking it through MCP until the timeout story is reliable across clients.researchMode tool and the CLI docs --research flag for deep, agent-driven documentation answers.ctx7 upgrade command. The CLI now checks for newer versions with cached state, shows a non-blocking notice before interactive commands, and provides safer upgrade guidance across npm, pnpm, bun, and ephemeral runner setups.ctx7 remove as the cleanup counterpart to ctx7 setup, with safer detection and removal behavior. The command now prompts only for agents with actual Context7 artifacts, preserves non-Context7 MCP configuration when removing entries, and includes stronger test coverage for JSON and TOML cleanup.