Skip to content

fix(deps): update minor and patch updates #178

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
renovate wants to merge 1 commit into
base: main
Choose a base branch
from
+2,331 −1,639
Open

fix(deps): update minor and patch updates #178

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 9 additions & 9 deletions package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,15 +45,15 @@
}
},

@greptile-apps greptile-apps Bot Jun 15, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 MCP background-connection breaking change from v0.3.0

In @anthropic-ai/claude-agent-sdk v0.3.142 (included in ~0.3.0), MCP servers now connect in the background by default — sessions start immediately and slow servers are reported as status: "pending" in the init event until ready. Previously the SDK waited up to 5 s for servers to connect before starting the first turn.

The agent configures a single, critical MCP server (@workos/mcp-docs-server) that provides the WorkOS documentation used throughout the integration workflow. Under the new default, the agent can begin its first turn before that server is ready, meaning WorkOS MCP tools may be absent or pending on turn 1. The existing AgentSignals.ERROR_MCP_MISSING guard only fires if the agent explicitly emits the [ERROR-MCP-MISSING] signal string — it will not fire for a pending-state MCP tool failure, so the regression could be silent.

To preserve the previous behaviour, either set MCP_CONNECTION_NONBLOCKING=0 in sdkEnv or add alwaysLoad: true to the workos MCP server entry in src/lib/agent-interface.ts.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

"dependencies": {
"@anthropic-ai/claude-agent-sdk": "~0.2.62",
"@anthropic-ai/sdk": "^0.78.0",
"@anthropic-ai/claude-agent-sdk": "~0.3.0",
"@anthropic-ai/sdk": "^0.105.0",
"@clack/core": "^1.0.1",
"@clack/prompts": "1.0.1",
"@clack/prompts": "1.6.0",
"@hono/node-server": "^1",
"@napi-rs/keyring": "^1.2.0",
"@workos-inc/node": "^8.7.0",
"@workos/migrations": "^2.0.0",
"@workos/openapi-spec": "^0.1.0",
"@workos/openapi-spec": "^0.8.0",

@greptile-apps greptile-apps Bot Jun 27, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Node engine conflict from transitive @workos/oagen dependency

@workos/openapi-spec@0.8.0 (previously no runtime deps) now carries @workos/oagen@0.22.7 as a regular dependency. That package declares engines: {node: '>=24.10.0'}, directly contradicting this project's own engines: {node: '>=22.11'}. Any install on Node 22 or 23 — including CI and user machines — will receive an engine-incompatibility warning from pnpm, and any environment running with engineStrict: true will fail outright.

@workos/oagen also pulls in native tree-sitter parsers for 9 languages (C#, Elixir, Go, Kotlin, PHP, Python, Ruby, Rust, TypeScript), and tree-sitter-kotlin is fetched directly from a GitHub tarball rather than the npm registry, which can fail silently in restricted-network CI environments. Given that the only runtime use of this package is require.resolve('@workos/openapi-spec/spec') to load a YAML file (see src/commands/api/catalog.ts:124), accepting this heavy dependency tree as a consequence of bumping @workos/openapi-spec seems worth verifying with the package owners.

Prompt To Fix With AI 
This is a comment left during a code review.
Path: package.json
Line: 56

Comment:
**Node engine conflict from transitive `@workos/oagen` dependency**

`@workos/openapi-spec@0.8.0` (previously no runtime deps) now carries `@workos/oagen@0.22.7` as a regular `dependency`. That package declares `engines: {node: '>=24.10.0'}`, directly contradicting this project's own `engines: {node: '>=22.11'}`. Any install on Node 22 or 23 — including CI and user machines — will receive an engine-incompatibility warning from pnpm, and any environment running with `engineStrict: true` will fail outright.

`@workos/oagen` also pulls in native tree-sitter parsers for 9 languages (C#, Elixir, Go, Kotlin, PHP, Python, Ruby, Rust, TypeScript), and `tree-sitter-kotlin` is fetched directly from a GitHub tarball rather than the npm registry, which can fail silently in restricted-network CI environments. Given that the only runtime use of this package is `require.resolve('@workos/openapi-spec/spec')` to load a YAML file (see `src/commands/api/catalog.ts:124`), accepting this heavy dependency tree as a consequence of bumping `@workos/openapi-spec` seems worth verifying with the package owners.

How can I resolve this? If you propose a fix, please make it concise.

"@workos/skills": "0.6.1",
"chalk": "^5.6.2",
"diff": "^8.0.3",
Expand All @@ -70,16 +70,16 @@
"zod": "^4.3.6"
},
"devDependencies": {
"@statelyai/inspect": "^0.4.0",
"@types/node": "~22.19.7",
"@types/opn": "5.1.0",
"@statelyai/inspect": "^0.7.0",
"@types/node": "~22.20.0",
"@types/opn": "5.5.0",
"@types/react": "^19.2.14",
"@types/semver": "^7.7.1",
"@types/yargs": "^17.0.35",
"@vitest/coverage-v8": "^4.0.18",
"@vitest/ui": "^4.0.18",
"dotenv": "^17.3.1",
"oxfmt": "^0.35.0",
"oxfmt": "^0.55.0",
"oxlint": "^1.50.0",
"p-limit": "^7.3.0",
"tsx": "^4.20.3",
Expand All @@ -89,7 +89,7 @@
"engines": {
"node": ">=22.11"
},
"packageManager": "pnpm@10.28.2",
"packageManager": "pnpm@10.34.4",
"scripts": {
"clean": "rm -rf ./dist",
"prebuild": "pnpm clean",
Expand Down
Loading
Loading