Skip to content

docs(limits): say setup forwards the selected MCP response budget - #8342

Open
chordpli wants to merge 1 commit into
morluto:mainfrom
chordpli:docs/setup-forwards-response-budget
Open

chordpli wants to merge 1 commit into
morluto:mainfrom
chordpli:docs/setup-forwards-response-budget

Conversation

@chordpli

@chordpli chordpli commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Fixes #7420.

docs/design/limits-and-recovery.md said the setup allowlist does not copy REA_MCP_MAX_RESPONSE_BYTES. That is wrong: the setting is in SELECTED_REGISTRATION_SETTINGS, setup forwards an explicit selection into the client registration, and docs/client-configuration.md already says so. The paragraph now states the actual behavior.

Problem and expected behavior

  • Trigger: a maintainer adding a headroom setting reads the response-budget example and concludes that setup leaves it out of registrations.
  • Expected: the design guide agrees with the setup allowlist and the client guide.

Change and scope

  • docs/design/limits-and-recovery.md: replace "The setup allowlist does not copy this setting. A new headroom setting should, following the regex deadline." with a statement that, like the regex deadline, the setting is in SELECTED_REGISTRATION_SETTINGS and setup forwards an explicit selection.
  • Not included: code changes. The setup behavior is unchanged and was already correct.

Follow the contribution scope.
Unresolved scope, authority, side effects, or required verification block
integration. Link the required maintainer scope decision for new providers or
capabilities involving target execution, injection, mutation, or protection
recovery; ordinary fixes within existing boundaries may state "not applicable".
Draft PRs may leave the scope decision pending and the readiness and merge checklists
unchecked. Maintainers can help resolve open questions.

Contract and boundary impact

  • Semantic owner and earliest changed stage: SELECTED_REGISTRATION_SETTINGS in src/application/SetupRegistrationEnvironment.ts (unchanged); only the design guide that describes it changes.
  • Contribution scope fit and linked maintainer decision: not applicable; documentation correction.
  • CLI and MCP/tool-catalog contract: none.
  • Provider, bridge, target-format, or platform compatibility: none.
  • Evidence, artifact, provenance, or reconstruction contract: none.
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): not applicable.
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact (CI generates and validates ignored catalogs and skills/; edit authored instructions in .agents/skills/reverse-engineer-anything/ and never commit build outputs): none.

Expected effects (check known effects; use documentation-only on its own).
Unchecked items do not establish absence; leave uncertainties visible.

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: none (documentation only).

  • Base reproduction or other evidence (executed): built CLI at 8282bc3c7 (this branch; the setup code is unchanged from main 60149282f), isolated HOME, no files written:

    env -i PATH="$PATH" HOME="$WORK/home" TMPDIR="$WORK/tmp" \
      REA_MCP_MAX_RESPONSE_BYTES=20971520 \
      node scripts/rea.mjs setup --client codex --dry-run --yes --json

    The planned configure_client:codex action reports Detected provider environment: REA_MCP_MAX_RESPONSE_BYTES=20971520. Without the variable, the plan does not mention it.

  • Source: SELECTED_REGISTRATION_SETTINGS lists "REA_MCP_MAX_RESPONSE_BYTES", and explicitSetupRegistrationEnvironment copies every listed key that the caller set.

  • User-visible CLI/MCP output (if applicable): none changed.

  • Remaining proof gaps: a non-dry-run setup that writes a client registration was not run.

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

At 8282bc3c7 (based on main 60149282f; macOS 26.5.2, Node 24.22.1):

  • npm run docs:check — passed
  • npm run format:check — passed
  • npm run test:local -- src/mcpStartupPolicy.test.ts — 6 passed (includes the explicit 20971520-byte response budget selection)

Compatibility, safety, and release

  • Breaking changes or migration steps: none.
  • Real Hopper/Ghidra, browser, or OS coverage: not applicable.
  • Package or release metadata impact: none.
  • Security, privacy, process, or containment review: none.

Author readiness

Human owner: @chordpli

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

The design guide said the setup allowlist does not copy
REA_MCP_MAX_RESPONSE_BYTES, but SELECTED_REGISTRATION_SETTINGS includes
it and setup forwards an explicit selection, as the client guide states.

Fixes morluto#7420
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 31, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-31T16:34:23.903125Z 8282bc3 PR opened
ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@greptile-apps

greptile-apps Bot commented Oct 31, 2026 •

Copy link
Copy Markdown
Contributor

RetriggerView in GreptileConfidence Score: 5/5

[Low impact] This documentation correction appears safe to merge.

Summary

Corrects docs/design/limits-and-recovery.md to say setup forwards an explicitly selected REA_MCP_MAX_RESPONSE_BYTES into client registrations.

  • The limits guide says setup forwards explicitly selected response budgets.

Reviews (1) · Last reviewed commit: "docs(limits): say setup forwards the sel..." · Reviewed by Greptile

This branch has not been deployed

No deployments
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.

[Bug] Runtime-settings guide incorrectly says setup omits the response-byte budget

1 participant