Skip to content

Do not send a locally minted run id as a run authorization binding - #3546

Merged
kojiwakayama merged 13 commits into
mainfrom
fix/local-dev-run-binding
Aug 10, 2026
Merged

Do not send a locally minted run id as a run authorization binding#3546
kojiwakayama merged 13 commits into
mainfrom
fix/local-dev-run-binding

Conversation

@kwakayama

@kwakayama kwakayama commented Aug 10, 2026

Copy link
Copy Markdown
Contributor

Problem

Veryfront dev creates local AG-UI and eval run IDs that do not identify control-plane runs. Exporting those IDs as integration authorization bindings causes valid local tool calls to be rejected.

Change

  • keep run IDs in AG-UI events, resume state, and tracing
  • mark locally generated AG-UI IDs and server-created eval IDs as non-binding
  • keep ordinary client-supplied AG-UI IDs eligible for the existing binding flow
  • omit non-binding IDs from REST integration metadata and the exact configured Veryfront control-plane MCP endpoint
  • retain IDs as correlation metadata for third-party MCP servers, including same-origin custom endpoints
  • preserve or clear the marker with the credential-owner context for nested remote tools

For a non-binding local run, integration execution deliberately falls back to the authenticated caller context instead of claiming a run-owned connection. Control-plane runs remain bound by the run ID in their signed token claim.

Validation

  • focused AG-UI, remote-tool, remote-MCP, nested-context, and localized-eval regressions
  • Deno and Node focused suites
  • npm package build, generated API references, formatting, lint, and typecheck
  • exact-head CI and merge-queue checks are required before merge

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown

Review Change Stack

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review
📝 Walkthrough

Walkthrough

AG-UI contexts now mark generated run IDs as non-binding for tool authorization. Remote tool and MCP metadata omit run_id only for explicitly non-binding control-plane calls. Nested credential contexts preserve or remove this marker according to the owner context.

Changes

Run ID authorization binding

Layer / File(s) Summary
Propagate run ID binding state
src/tool/types.ts, src/agent/ag-ui/handler.ts, src/agent/ag-ui/handler.test.ts
The execution context carries runIdBindsToolAuthorization. AG-UI preserves the marker for generated run IDs across direct, injected-tool, and beforeStream replacement contexts.
Serialize remote authorization metadata
src/integrations/remote-tools.ts, src/integrations/remote-tools.test.ts, src/tool/remote-mcp.ts, src/tool/remote-mcp.test.ts
Remote tool calls omit run_id only when the flag is exactly false. Veryfront control-plane MCP calls apply the same rule, while third-party MCP calls retain run_id.
Propagate nested credential context
src/agent/runtime/mcp-server-tool-sources.ts, src/agent/runtime/mcp-server-tool-sources.cross-runtime.test.ts
Credential-owner binding preserves an explicitly defined authorization marker and removes it when the owner context leaves it undefined.
Refresh API source references
docs/api-reference/veryfront/agent.md, docs/api-reference/veryfront/integrations.md, docs/api-reference/veryfront/tool.md
API reference links use updated source locations, and the RemoteToolSource type is listed.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Sequence Diagram(s)

sequenceDiagram
  participant AGUIHandler
  participant ToolExecutionContext
  participant RemoteTools
  participant RemoteMCP
  participant VeryfrontControlPlane
  AGUIHandler->>ToolExecutionContext: create run context
  ToolExecutionContext->>RemoteTools: provide runId and binding flag
  RemoteTools->>RemoteTools: omit runId when flag is false
  ToolExecutionContext->>RemoteMCP: provide endpoint and binding flag
  RemoteMCP->>VeryfrontControlPlane: send metadata without run_id
Loading

Suggested reviewers: kojiwakayama

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 28.57% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title clearly summarizes the primary change: locally minted run IDs are excluded from authorization bindings while remaining available for runtime use.
✨ Finishing Touches 💡 1
📝 Generate docstrings 💡
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch fix/local-dev-run-binding

Comment @coderabbitai help to get the list of available commands.

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 977b9406ef

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/agent/ag-ui/handler.ts Outdated
Comment thread src/agent/ag-ui/handler.ts Outdated

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/agent/ag-ui/handler.ts`:
- Around line 330-338: In both AG-UI streaming paths, preserve the non-binding
authorization marker when the handler generated the run ID: after selecting
beforeStreamResult?.context as the final context, reapply
runIdBindsToolAuthorization: false whenever clientRunId is absent. Update the
final-context handling near the shown buildStreamContext flow and its
counterpart, while leaving contexts for client-supplied run IDs unchanged.

In `@src/integrations/remote-tools.ts`:
- Line 127: Add focused regression coverage for the authorization contract
around runIdBinds and the request-building flow: verify absent client runId
preserves the generated lifecycle ID while omitting serialized run_id, supplied
runId is serialized, no marker preserves existing behavior, and replacement
context keeps the non-binding marker effective. Make the test fail before
implementation, then update the relevant remote-tools logic to satisfy it
without changing unrelated behavior.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1a43738c-962e-4105-97fc-24bcf8908c35

📥 Commits

Reviewing files that changed from the base of the PR and between 48cd2d5 and 977b940.

📒 Files selected for processing (3)
  • src/agent/ag-ui/handler.ts
  • src/integrations/remote-tools.ts
  • src/tool/types.ts

Comment thread src/agent/ag-ui/handler.ts Outdated
Comment thread src/integrations/remote-tools.ts

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/agent/ag-ui/handler.ts`:
- Around line 150-153: Add focused regression tests in handler.test.ts for both
streaming paths and both generated and client-supplied AG-UI run IDs. Cover
direct and injected-tool execution, have the replacement context return a fresh
context without the marker, and assert the final agent or runtime context
contains runIdBindsToolAuthorization: false.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: ecea2012-0d59-4dbb-940e-391853128f16

📥 Commits

Reviewing files that changed from the base of the PR and between 977b940 and aaed0bd.

📒 Files selected for processing (1)
  • src/agent/ag-ui/handler.ts

Comment thread src/agent/ag-ui/handler.ts Outdated
@kwakayama

Copy link
Copy Markdown
Contributor Author

Review: 58/100 — right diagnosis, incomplete fix, red CI

The core insight is good and the measured A/B evidence is the best part of this PR. Sending a locally minted run_<uuid> as an authorization binding is genuinely wrong, and keeping the id for AG-UI events, the resume session manager and the run.id trace attribute is the correct call. I verified that last point: buildRuntimeToolTraceAttributes reads input.context?.runId (src/agent/runtime/index.ts:468), so dropping the field outright would silently lose the trace attribute. The marker approach is justified.

I also independently confirmed the cloud-runs argument. mintRuntimeInvocationAuthToken sets runId: run.runId on both project-backed branches, and callIntegrationTool computes claimedRunId ?? suppliedRunId. The claim wins. Scheduled and connected-agent runs are unaffected.

Below is what blocks merge.


P0 — CI is red, and it is this PR

ci (lint) fails. I reproduced it locally:

docs/api-reference is stale:
  outdated: veryfront/agent.md
  outdated: veryfront/integrations.md
  outdated: veryfront/tool.md

Every stale line is a line-number shift caused by exactly this diff — handler.ts +11, remote-tools.ts +5, types.ts +3. Nothing pre-existing. ToolExecutionContext is a public exported type, so adding a field trips the generated reference gate.

Fix: deno task docs, commit the result.

P0 — the same bug is unpatched on the MCP path

snapshotToolExecutionContext is not the only exporter of context.runId. src/tool/remote-mcp.ts:811:

function buildRunContextMeta(context: ToolExecutionContext | undefined) {
  const meta: Record<string, unknown> = {};
  if (typeof context?.runId === "string" && context.runId.length > 0) {
    meta.run_id = context.runId;
  }
  ...
}

That _meta.run_id lands in the API at src/api/http/mcp/handler/integration-requests.ts:123:

const runContext = {
  ...(typeof meta.run_id === 'string' ? { runId: meta.run_id } : {}),
  ...
}
await callIntegrationTool(toolName, toolArgs, ctx, runContext)

Same function. Same runId && !runDeclaredTool gate. Same "Run context is not authorized for this integration tool" string. So an integration reached over remote MCP in veryfront dev is still denied. The verification only exercised the REST /integrations/tools/call route, so this path was never measured.

P1 — the marker is stripped on the nested/delegate path

src/agent/runtime/mcp-server-tool-sources.ts:138:

const REMOTE_TOOL_CREDENTIAL_CONTEXT_KEYS = ["authToken", "runId", "agentId"] as const;

withBoundRemoteToolContext spreads the nested context, then overwrites those three keys from the credential owner. runIdBindsToolAuthorization is not in the list. Two failure modes fall out:

  • Owner context carries the marker, nested context does not. runId is copied, the marker is not. The locally minted id is exported as binding again — the fix is bypassed.
  • Nested context carries the marker, owner context has a real control-plane runId. The marker survives the spread and suppresses a legitimate binding.

This is the third instance of the same failure mode. Commit aaed0bd9d already had to reapply the marker at two beforeStream sites for exactly this reason. That is the cost of a fail-open flag propagated by convention through Record<string, unknown> spreads — every future context handoff has to remember it, and nothing catches a miss.

P1 — no tests

Zero test files in the diff. The marker is fail-open by design, and it has already been dropped once during review. Nothing pins:

  • buildStreamContext emits runIdBindsToolAuthorization: false
  • the marker survives a beforeStream that returns a fresh context object
  • snapshotToolExecutionContext suppresses on false and only on false
  • an absent marker still exports runId

Those are cheap unit tests against the exact regressions this branch already hit.

P1 — the central premise is overstated

The run binding only narrows a permission requireIntegrationCapability already granted

That is not what the code does. In callIntegrationTool, runDeclaredTool also selects the executing identity:

const executionUserId = getIntegrationExecutionUserId(toRunAuthorizationActor(ctx), runDeclaredTool)
await executeIntegrationTool({
  projectId: runDeclaredTool?.projectId ?? ctx.projectId ?? undefined,
  ...(executionUserId ? { userId: executionUserId } : {}),
  ...(runDeclaredTool ? { runDeclaredTool } : {}),
})

getIntegrationExecutionUserId returns runDeclaredTool.ownerUserId when the declaration resolves, and falls back to actor.userId when it does not. So dropping runId does not merely stop narrowing. It switches which OAuth connection executes the tool, from the run-declared one to the caller's own, and drops the connection binding (getRunAuthorizationBinding, project vs. user scope, service identity) entirely.

That may well be the behaviour you want in local dev. But it should be stated as the deliberate change it is, not as a no-op.

P1 — the success case was never observed

This matters because of the point above. The PR reports reconnect_required and attributes it to an expired connection. There is a second explanation that fits the same evidence: suppressing runId moved execution off the run-declared connection and onto the caller's personal one, which does not exist. The two are indistinguishable from what was measured. "A direct authenticated call returns the identical error" does not separate them — a direct call has no run declaration either, so both hypotheses predict it.

Reconnect the connection and get one green tool call. Without that, the branch is unverified in the case it exists to fix.

P2 — the description contradicts the code

buildStreamContext marks the id non-binding when the client did not supply one

It does not. aaed0bd9d removed that branch. The marker is now unconditional, which the code comment says plainly. The Verification section is stale for the same reason:

with a client-supplied runId the call is still denied (correct, that id is binding)

That was measured against 977b9406e. Under the current head a client-supplied id is also suppressed, so that line describes behaviour the branch no longer has. Please rewrite both sections against the merged state.

To be clear, the change in aaed0bd9d is correct — a client-supplied AG-UI run id is an untrusted request field, not proof of a control-plane run. Only the prose is out of date.

P2 — duplicate buildStreamContext

There are now three functions with this name: handler.ts:139, runtime-handler.ts:81, detached-start.ts:33. Only the first sets the marker. That is correct today — the runtime handler binds through the token claim, and detached-start is driven by durable-chat-run-start.ts where the id really is a control-plane run. But the correctness is invisible at each call site. A one-line comment in the two unmarked copies saying why they stay bindable would stop the next person from "fixing" them.


Suggested shape

Consider inverting the flag so it fails closed. An explicit runIdBindsToolAuthorization: true set only where a control-plane run id is known, checked as !== true at the two export sites, cannot be lost by an object spread — a dropped key becomes "do not bind" instead of "bind". That also removes the need to reapply it after beforeStream and makes the REMOTE_TOOL_CREDENTIAL_CONTEXT_KEYS gap harmless. It is a larger diff because every real-run producer has to opt in, which is precisely the audit worth doing once.

To merge

  1. deno task docs and commit — unblocks CI.
  2. Apply the same suppression in buildRunContextMeta (remote-mcp.ts).
  3. Add runIdBindsToolAuthorization to REMOTE_TOOL_CREDENTIAL_CONTEXT_KEYS, or invert the flag.
  4. Tests for the four cases above.
  5. Rewrite the Change and Verification sections against the current head.
  6. One green integration tool call end to end.

The diagnosis is worth keeping. The evidence gathering is genuinely strong. It needs another pass before it lands.

kwakayama and others added 5 commits August 10, 2026 19:50
veryfront dev mints run_<uuid> in-process. That id is not a control-plane
run, so agentRunRepository.getByRunId finds nothing and every integration
tool call is denied with "Run context is not authorized for this
integration tool".

The run id itself must stay: AG-UI RUN_STARTED/RUN_FINISHED, the resume
session manager and the run.id trace attribute all depend on it. Only its
export as an authorization binding is wrong.

buildStreamContext now marks the id non-binding when the client did not
supply one, and snapshotToolExecutionContext drops runId on strict
=== false. Absence of the marker preserves the previous behaviour exactly,
so every other context producer is unchanged.

Cloud runs are unaffected: runtime-auth-token.ts mints tokens with
runId: run.runId on both project-backed branches, and the API computes
runId = claimedRunId ?? suppliedRunId, so the seal still engages from the
token claim.
Two review findings.

An AG-UI run id supplied by the client is an untrusted request field, not
proof of a control-plane run. Treating it as binding meant any client that
generates its own per-request id still got denied for the same missing-run
reason this branch fixes. Hosted durable runs bind through the token claim
in createAgUiRuntimeHandler, so createAgUiHandler now marks the id
non-binding unconditionally. That also removes the clientRunId branching.

beforeStream may return a fresh context object rather than spreading the
one it was given. finalContext replaced the whole object and dropped the
marker, so snapshotToolExecutionContext read the absent marker as binding
and exported the generated id again. The marker is now reapplied to
finalContext in both streaming paths.
deno task docs. Line number shifts only, no content changes.
@kojiwakayama
kojiwakayama force-pushed the fix/local-dev-run-binding branch from 0470b77 to 40119f7 Compare August 10, 2026 17:51
@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: 40119f7df8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@kojiwakayama
kojiwakayama added this pull request to the merge queue Aug 10, 2026
Review found the same defect in two more places.

remote-mcp.ts buildRunContextMeta exported context.runId as _meta.run_id,
which the API reads back into the same callIntegrationTool gate. An
integration reached over remote MCP was still denied. It now honours the
marker like the REST path.

mcp-server-tool-sources.ts copies authToken, runId and agentId from the
credential owner into a nested context. The marker was not in that list,
so it was dropped when the owner supplied a run id, re-exporting a local
id as binding. Added it, and the marker is now cleared when the owner has
a real run id and no marker, so a stale nested marker cannot suppress a
legitimate binding.

Three regression tests: suppression on the marker, run_id still sent when
the marker is absent, and suppression only on strict false.
The marker is fail-open, so a truthy, absent or malformed value must
still export the run id. Only an explicit false suppresses it.
@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. Hooray!

Reviewed commit: 40119f7df8

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@kwakayama
kwakayama removed this pull request from the merge queue due to a manual request Aug 10, 2026
@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7b8e83358b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/tool/remote-mcp.ts Outdated
Review: the marker means the run id must not be used as a Veryfront
authorization binding, not that it is secret. Suppressing _meta.run_id for
every remote MCP server stripped correlation metadata that third-party
servers had always received.

Suppression is now scoped to endpoints whose origin matches the configured
Veryfront API base URL, which is the only handler that reads _meta.run_id
back into the integration authorization gate.

The existing non-binding test asserted suppression against an endpoint that
was not the control plane, so it now sets VERYFRONT_API_BASE_URL to match.
Added the converse: a third-party origin still receives run_id.

The third-party endpoint is a public address rather than a TEST-NET one
because the egress guard classifies TEST-NET as internal and blocks it.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/agent/ag-ui/handler.test.ts`:
- Around line 185-207: Update the AG-UI handler behavior so only locally minted
run IDs set runIdBindsToolAuthorization to false; client-supplied IDs must
retain the default authorization binding. Adjust the expectations in
src/agent/ag-ui/handler.test.ts lines 185-207 and 400-401 for the direct-stream
and injected-tool cases, respectively, while preserving the run ID values in the
responses.

In `@src/agent/runtime/mcp-server-tool-sources.test.ts`:
- Around line 597-611: The test around
bindRuntimeRemoteToolSourcesToCredentialOwner must cover owner contexts with a
defined runId and runIdBindsToolAuthorization false, plus an owner context where
the marker is absent. Add assertions for both cases confirming the owner context
replaces the nested run context, including the expected runId and marker
behavior, so the marker-copy and deletion branches execute.

In `@src/tool/remote-mcp.test.ts`:
- Around line 299-300: In src/tool/remote-mcp.test.ts at lines 299-300 and
341-342, replace Deno.env access with the runtime-neutral scoped environment
helper used by the tests; at lines 335-336 and 373-374, restore each scoped
environment in a finally block so cleanup runs on failures. In
src/agent/runtime/mcp-server-tool-sources.test.ts at line 587, register the test
case through describe() and it() imported from `#veryfront/testing/bdd.ts`.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 1d51c0b2-e520-4c77-8dd5-25721f8ac095

📥 Commits

Reviewing files that changed from the base of the PR and between aaed0bd and 11d6582.

📒 Files selected for processing (12)
  • docs/api-reference/veryfront/agent.md
  • docs/api-reference/veryfront/integrations.md
  • docs/api-reference/veryfront/tool.md
  • src/agent/ag-ui/handler.test.ts
  • src/agent/ag-ui/handler.ts
  • src/agent/runtime/mcp-server-tool-sources.test.ts
  • src/agent/runtime/mcp-server-tool-sources.ts
  • src/integrations/remote-tools.test.ts
  • src/integrations/remote-tools.ts
  • src/tool/remote-mcp.test.ts
  • src/tool/remote-mcp.ts
  • src/tool/types.ts
💤 Files with no reviewable changes (1)
  • docs/api-reference/veryfront/agent.md
🚧 Files skipped from review as they are similar to previous changes (3)
  • src/integrations/remote-tools.ts
  • src/tool/types.ts
  • src/agent/ag-ui/handler.ts

Comment thread src/agent/ag-ui/handler.test.ts Outdated
Comment thread src/agent/runtime/mcp-server-tool-sources.test.ts Outdated
Comment thread src/tool/remote-mcp.test.ts Outdated
@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 11d6582c71

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/tool/remote-mcp.ts Outdated
remote-mcp.test.ts used Deno.env, which Node and Bun runners can skip,
and restoration did not run on failure. Replaced with setEnv/deleteEnv
from compat/process and an afterEach restore.

mcp-server-tool-sources.test.ts did not exercise the marker copy or the
delete branch, because the owner context omitted runId. Added both: an
owner run id carrying a non-binding marker replaces the nested context,
and an owner run id without a marker clears a stale nested one.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/agent/runtime/mcp-server-tool-sources.test.ts`:
- Line 614: Replace both Deno.test declarations in the existing suite with it()
calls, and import describe and it from `#veryfront/testing/bdd.ts`. Preserve each
test’s name, body, and existing describe grouping so the cases run across all
supported runtimes.
🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: cd531b7e-952b-4b9c-a44b-e61b66302e8a

📥 Commits

Reviewing files that changed from the base of the PR and between 11d6582 and 0e23d68.

📒 Files selected for processing (2)
  • src/agent/runtime/mcp-server-tool-sources.test.ts
  • src/tool/remote-mcp.test.ts
🚧 Files skipped from review as they are similar to previous changes (1)
  • src/tool/remote-mcp.test.ts

Comment thread src/agent/runtime/mcp-server-tool-sources.test.ts Outdated
@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@chatgpt-codex-connector chatgpt-codex-connector Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: c27d3c5e78

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment thread src/agent/ag-ui/handler.ts Outdated
@kojiwakayama

Copy link
Copy Markdown
Contributor

@codex review

@kojiwakayama

Copy link
Copy Markdown
Contributor

@coderabbitai review

@coderabbitai

coderabbitai Bot commented Aug 10, 2026

Copy link
Copy Markdown
⚠️ Action not completed

Review rate limited.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

@chatgpt-codex-connector

Copy link
Copy Markdown

Codex Review: Didn't find any major issues. You're on a roll.

Reviewed commit: 3774dd15b1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

@kojiwakayama
kojiwakayama added this pull request to the merge queue Aug 10, 2026
Merged via the queue into main with commit 6c4bddd Aug 10, 2026
33 checks passed
@kojiwakayama
kojiwakayama deleted the fix/local-dev-run-binding branch August 10, 2026 19:15
@kwakayama kwakayama mentioned this pull request Aug 10, 2026
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.

2 participants