[GH-ISSUE #3442] [Workflow] Consider raising concurrent open PR cap or allowlisting active contributors #1285

New issue

Closed

opened 2026-10-16 21:03:46 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented 2026-10-16 21:03:46 +00:00

Owner

Copy link

Originally created by @matbrgz on GitHub (Oct 14, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/3442

Background

GitHub enforces a repository-level cap on concurrent open pull requests for contributors without write access:

"Users without write access can have up to 3 pull requests open at a time. Merge or close your open pull requests to submit a new one."

Current Situation

As an active contributor preparing independent, scoped contributions across distinct subsystems (such as client integrations like OpenClaw in #3100, Ghidra analysis fixes in #3029, and CLI batching in #3028), the 3-PR limit blocks submitting additional discrete contributions (e.g. the documentation disclaimer clarification reported in #3441) while prior PRs are awaiting maintainer review or qualification runs.

In accordance with REA's contributing guidelines (one focused outcome per PR to keep review scopes tight and traceable), contributors cannot bundle disparate changes into a single PR.

Suggestion / Request for Maintainers

Would maintainers consider:

1. Increasing the repository's open pull request limit for external contributors (e.g. from 3 to 5 or higher); or
2. Adding established active contributors to the GitHub PR creation bypass list (bypassedUsers under repository settings / pullRequestCreationCapConfig), or granting triage permissions?

This would help active contributors submit independent, fully-verified scoped PRs without getting blocked while earlier submissions are in the review queue.

Originally created by @matbrgz on GitHub (Oct 14, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/3442 [](https://github.com/morluto/rea) [](https://github.com/morluto/rea) [](https://github.com/morluto/rea) [](https://github.com/morluto/rea) ### Background GitHub enforces a repository-level cap on concurrent open pull requests for contributors without write access: > *"Users without write access can have up to 3 pull requests open at a time. Merge or close your open pull requests to submit a new one."* ### Current Situation As an active contributor preparing independent, scoped contributions across distinct subsystems (such as client integrations like OpenClaw in #3100, Ghidra analysis fixes in #3029, and CLI batching in #3028), the 3-PR limit blocks submitting additional discrete contributions (e.g. the documentation disclaimer clarification reported in #3441) while prior PRs are awaiting maintainer review or qualification runs. In accordance with REA's contributing guidelines (one focused outcome per PR to keep review scopes tight and traceable), contributors cannot bundle disparate changes into a single PR. ### Suggestion / Request for Maintainers Would maintainers consider: 1. Increasing the repository's open pull request limit for external contributors (e.g. from 3 to 5 or higher); or 2. Adding established active contributors to the GitHub PR creation bypass list (`bypassedUsers` under repository settings / `pullRequestCreationCapConfig`), or granting triage permissions? This would help active contributors submit independent, fully-verified scoped PRs without getting blocked while earlier submissions are in the review queue.

bsakaguchi referenced this issue 2026-10-17 21:10:00 +00:00

[PR #1285] [MERGED] fix(hopper): probe interior navigation from multi-byte instructions #2766

bsakaguchi closed this issue 2026-10-31 00:30:27 +00:00

bsakaguchi commented 2026-10-31 00:30:27 +00:00

Author

Owner

Copy link

@XiaoBinGan commented on GitHub (Oct 22, 2026):

Adding a concrete data point to this proposal, as an active contributor who is currently blocked by the cap.

Who I am. I have 11 merged PRs here (apple Interface Builder archives, sigrok selector classification, CLI input validation, domain error projection, artifact ZIP admission, and the default-branch static-check repair), each squash-merged with a regression test or a real-producer control. I have also had 8 PRs closed after the maintainer reimplemented the same fix on main (#2246, #2251, #2709, #2723, #3141, #3157, #3240, #2921) — which I read as "the analysis was right, the delivery was slower than the maintainer's own fix". I am not asking to bypass review.

The problem. The three-open-PR cap, not review capacity, now sets my throughput. Concretely:

• Median time-to-merge on my merged PRs is 2.4 h, so a slot is idle most of the day while finished work sits verified locally.
• Four of my PRs were closed by me specifically to free a slot (#3122, #3563, #3572, #4828) — verified work withdrawn rather than reviewed.
• When a slot frees, the issue is often already fixed by someone else. My PR #5854 (the #5849 fix) was superseded by #5858 while it waited for a slot, despite a CI-green, conflict-free branch.
• A dirty PR (#5854 before I closed it) consumes a slot while being unmergeable, so effective capacity is below three.
• Draft PRs consume a slot too: my draft #6074 holds one while it waits for its readiness declaration.

Right now all three slots are held by finished work — #5816, #5962 and #6074 — and I have a fourth change that is committed, formatted, typechecked and covered by 38 passing tests. I cannot submit it. The API refuses with XiaoBinGan does not have the correct permissions to execute CreatePullRequest. That is the cap, not a code or review problem.

What I am asking for. Either of these would remove the bottleneck:

1. An allowlist that exempts an established contributor from the three-open-PR cap, keeping every other rule unchanged (human ownership, readiness declarations, CI, one focused outcome per PR, the same review and close-without-merge policy); or
2. Write access, with whatever additional obligations you want attached. I am happy to be bound by the same CONTRIBUTING.md readiness and verification requirements as any PR author, and to keep my own open PR count at or below any number you name.

If neither is possible, a stated preferred way to queue verified changes would still help — for example whether it is acceptable to keep extra verified branches on my fork and open PRs one at a time as slots free, and whether a dirty PR should be closed immediately rather than held.

I am not asking for merge rights. Only for the ability to keep one focused, verified change in flight per slot, instead of one per slot per day.

One more observation, offered in good faith. I can see you pushing your own fixes directly onto my branches — 82b9d6920 on #5816, 3a7829bad plus a Merge main into firmware staging budget on #5962. I read that as review-by-repair, and I am grateful for it: it is faster than writing review comments, and it showed me precisely what my fixes were missing. But it also means the maintainer is doing the final 20% of every contribution, which is exactly the work an allowlist would let me do myself. If you would rather keep repairing my branches than grant access, that is a clear enough answer — say so and I will keep the PRs coming. I only want to stop spending your time on the last mile.

<!-- gh-comment-id:6346556406 --> @XiaoBinGan commented on GitHub (Oct 22, 2026): Adding a concrete data point to this proposal, as an active contributor who is currently blocked by the cap. **Who I am.** I have 11 merged PRs here (apple Interface Builder archives, sigrok selector classification, CLI input validation, domain error projection, artifact ZIP admission, and the default-branch static-check repair), each squash-merged with a regression test or a real-producer control. I have also had 8 PRs closed *after* the maintainer reimplemented the same fix on `main` (#2246, #2251, #2709, #2723, #3141, #3157, #3240, #2921) — which I read as "the analysis was right, the delivery was slower than the maintainer's own fix". I am not asking to bypass review. **The problem.** The three-open-PR cap, not review capacity, now sets my throughput. Concretely: - Median time-to-merge on my merged PRs is 2.4 h, so a slot is idle most of the day while finished work sits verified locally. - Four of my PRs were closed by me specifically to free a slot (#3122, #3563, #3572, #4828) — verified work withdrawn rather than reviewed. - When a slot frees, the issue is often already fixed by someone else. My PR #5854 (the #5849 fix) was superseded by #5858 while it waited for a slot, despite a CI-green, conflict-free branch. - A `dirty` PR (#5854 before I closed it) consumes a slot while being unmergeable, so effective capacity is below three. - Draft PRs consume a slot too: my draft #6074 holds one while it waits for its readiness declaration. Right now all three slots are held by finished work — #5816, #5962 and #6074 — and I have a fourth change that is committed, formatted, typechecked and covered by 38 passing tests. I cannot submit it. The API refuses with `XiaoBinGan does not have the correct permissions to execute CreatePullRequest`. That is the cap, not a code or review problem. **What I am asking for.** Either of these would remove the bottleneck: 1. An allowlist that exempts an established contributor from the three-open-PR cap, keeping every other rule unchanged (human ownership, readiness declarations, CI, one focused outcome per PR, the same review and close-without-merge policy); or 2. Write access, with whatever additional obligations you want attached. I am happy to be bound by the same CONTRIBUTING.md readiness and verification requirements as any PR author, and to keep my own open PR count at or below any number you name. If neither is possible, a stated preferred way to queue verified changes would still help — for example whether it is acceptable to keep extra verified branches on my fork and open PRs one at a time as slots free, and whether a `dirty` PR should be closed immediately rather than held. I am not asking for merge rights. Only for the ability to keep one focused, verified change in flight per slot, instead of one per slot per day. **One more observation, offered in good faith.** I can see you pushing your own fixes directly onto my branches — `82b9d6920` on #5816, `3a7829bad` plus a `Merge main into firmware staging budget` on #5962. I read that as review-by-repair, and I am grateful for it: it is faster than writing review comments, and it showed me precisely what my fixes were missing. But it also means the maintainer is doing the final 20% of every contribution, which is exactly the work an allowlist would let me do myself. If you would rather keep repairing my branches than grant access, that is a clear enough answer — say so and I will keep the PRs coming. I only want to stop spending your time on the last mile.

bsakaguchi commented 2026-10-31 00:30:27 +00:00

Author

Owner

Copy link

@XiaoBinGan commented on GitHub (Oct 25, 2026):

An update with one new, verifiable fact, then I will stop asking in this thread.

The precedent. Write access is granted in this repository, and it does not take long. kaoru0822-kitauji's first PR here was #569 on 2026-10-05T13:07Z. Between then and 16:19Z morluto merged ten of their PRs, and at 2026-10-06T05:14Z PR #651 was merged by kaoru0822-kitauji itself — write access after about 16 hours. gensokyo-dev's first PR (#5002, 2026-10-18T08:59Z) was already self-merged, so access came before it. Both are now merging other people's PRs too.

My record. Fourteen merged PRs since 2026-10-12, over 12.7 days. The last four: #5816 merged by morluto, #6479 and #6971 merged by baron, and #7033 open and green. Median turnaround has been fast and the reviews have been generous. I have never had write access here, so every one of those went through a slot that could have been a fourth parallel change.

What I am trying to work out. Either the bar is something other than a merged-PR count, in which case I would genuinely like to know what it is so I can meet it — or the decision is discretionary and simply has not come up. Both are fine answers. The second one does cost measurable work: this week two PRs (#6074 and #5962) were closed as superseded because main implemented the same fix while they waited, which is the same outcome as #5854 last week.

If the answer is no, or if this is the wrong place to ask, please just say so and I will drop it and keep sending PRs. I would far rather hear a plain no than keep guessing. @baron, @morluto — either of you can settle it in one line and I will stop.

<!-- gh-comment-id:6400469024 --> @XiaoBinGan commented on GitHub (Oct 25, 2026): An update with one new, verifiable fact, then I will stop asking in this thread. **The precedent.** Write access is granted in this repository, and it does not take long. `kaoru0822-kitauji`'s first PR here was #569 on 2026-10-05T13:07Z. Between then and 16:19Z morluto merged ten of their PRs, and at 2026-10-06T05:14Z PR #651 was merged by `kaoru0822-kitauji` itself — write access after about 16 hours. `gensokyo-dev`'s first PR (#5002, 2026-10-18T08:59Z) was already self-merged, so access came before it. Both are now merging other people's PRs too. **My record.** Fourteen merged PRs since 2026-10-12, over 12.7 days. The last four: #5816 merged by morluto, #6479 and #6971 merged by baron, and #7033 open and green. Median turnaround has been fast and the reviews have been generous. I have never had write access here, so every one of those went through a slot that could have been a fourth parallel change. **What I am trying to work out.** Either the bar is something other than a merged-PR count, in which case I would genuinely like to know what it is so I can meet it — or the decision is discretionary and simply has not come up. Both are fine answers. The second one does cost measurable work: this week two PRs (#6074 and #5962) were closed as superseded because `main` implemented the same fix while they waited, which is the same outcome as #5854 last week. If the answer is no, or if this is the wrong place to ask, please just say so and I will drop it and keep sending PRs. I would far rather hear a plain no than keep guessing. @baron, @morluto — either of you can settle it in one line and I will stop.

bsakaguchi commented 2026-10-31 00:30:28 +00:00

Author

Owner

Copy link

@baron commented on GitHub (Oct 26, 2026):

@XiaoBinGan appreciate your passion and raising this issue with us. We've raised the contribution limit to 8 so I feel that should give you a much improved experience. Also if you're on REA discord find me and add me as a friend and if there's anything you need me to look at I'll be happy to help.

Still lots to improve I'm sure but we will get better over time. Thank you for your patience!

<!-- gh-comment-id:6410156258 --> @baron commented on GitHub (Oct 26, 2026): @XiaoBinGan appreciate your passion and raising this issue with us. We've raised the contribution limit to 8 so I feel that should give you a much improved experience. Also if you're on REA discord find me and add me as a friend and if there's anything you need me to look at I'll be happy to help. Still lots to improve I'm sure but we will get better over time. Thank you for your patience!

bsakaguchi commented 2026-10-31 00:30:28 +00:00

Author

Owner

Copy link

@baron commented on GitHub (Oct 26, 2026):

@matbrgz thank you for filing this issue. The limit is now 8. We've had to tread carefully with the sudden spotlight. Now that we've implemented some things and gotten through some milestones we can finally increase the limit. Appreciate your passion and patience! Thank you and everyone for making this project better.

<!-- gh-comment-id:6410191946 --> @baron commented on GitHub (Oct 26, 2026): @matbrgz thank you for filing this issue. The limit is now 8. We've had to tread carefully with the sudden spotlight. Now that we've implemented some things and gotten through some milestones we can finally increase the limit. Appreciate your passion and patience! Thank you and everyone for making this project better.

bsakaguchi commented 2026-11-03 00:29:30 +00:00

Author

Owner

Copy link

@XiaoBinGan commented on GitHub (Nov 2, 2026):

Following up on this issue, because the outcome of the last round was concrete and I want to give you the data to decide the next step the same way.

What changed after your reply. You raised the cap from 3 to 8 on 2026-10-26. It worked exactly as you predicted: throughput stopped being slot-bound. I have since shipped 23 merged PRs on this repository. The eight-open-PR limit has also effectively lifted — I can now open more than eight, so that part of the friction is gone. Thank you for that; it was the right call.

Where the remaining friction is now. Not slots, and not review findings. It is that finished work sits behind a merge that only a maintainer can perform, while I cannot pick up the next unit of work until that happens to a batch of it. As of today I have 11 open PRs, all 11 green and mergeable, with zero unanswered review findings:

• #8557 resolves #8453 (malformed Evidence file diagnostics overflow the MCP response and drop the file path). Three review rounds, cleaned.
• #8266 resolves #8554 (socket resource analysis misclassifies unary arguments). Every row of that report's table is fixed on the branch; seven review rounds, cleaned.
• The other nine are the same family of static-analysis correctness fixes, each with a red/green regression.

These are not untested drafts. To give you a sense of what "cleaned" means here: #8266 took seven review rounds and #8624 five, because each one is a literal-boundary rule and the reviewer legitimately found another boundary every round. I fixed every one of them rather than arguing, and each fix now carries a test that fails without it.

The specific ask, and why it is this one. The request in the title — allowlisting active contributors — is the right lever, not because I want a badge, but because of what the two contributors who already have write access do with it: kaoru0822-kitauji (12 of the last 20 merges) and gensokyo-dev (3) merge their own verified work. That is the model I am asking to be held to. If I can merge my own green PRs, those 11 land in one pass and I start the next batch the same hour instead of waiting for a review window.

What I am not asking for. Not merge rights on anyone else's PR, not a bypass of the review gate, not the ability to merge something with an open finding. The commitment would be the same one I have kept for all 23 merged PRs: nothing merged while a review finding is unanswered, nothing merged without a red/green regression, and the full suite green on the exact commit being merged.

The bar question, stated plainly. I asked this before and I will ask it once, concretely, rather than guessing: if the bar is not "merged-PR count plus a clean review record", tell me what it is. My record is 23 merged, every open PR green and review-clean, two of them resolving issues you filed this month. If that is not the bar, I genuinely do not know what is, and I would rather be told "no, and here is why" than keep inferring it.

If you would rather discuss this on Discord, that is fine too — you mentioned finding you there. But I wanted the reasoning and the numbers on the record in this thread, since this is where the last decision was made.

<!-- gh-comment-id:6582908616 --> @XiaoBinGan commented on GitHub (Nov 2, 2026): Following up on this issue, because the outcome of the last round was concrete and I want to give you the data to decide the next step the same way. **What changed after your reply.** You raised the cap from 3 to 8 on 2026-10-26. It worked exactly as you predicted: throughput stopped being slot-bound. I have since shipped **23 merged PRs** on this repository. The eight-open-PR limit has also effectively lifted — I can now open more than eight, so that part of the friction is gone. Thank you for that; it was the right call. **Where the remaining friction is now.** Not slots, and not review findings. It is that finished work sits behind a merge that only a maintainer can perform, while I cannot pick up the next unit of work until that happens to a batch of it. As of today I have **11 open PRs, all 11 green and mergeable, with zero unanswered review findings**: - `#8557` resolves `#8453` (malformed Evidence file diagnostics overflow the MCP response and drop the file path). Three review rounds, cleaned. - `#8266` resolves `#8554` (socket resource analysis misclassifies unary arguments). Every row of that report's table is fixed on the branch; seven review rounds, cleaned. - The other nine are the same family of static-analysis correctness fixes, each with a red/green regression. These are not untested drafts. To give you a sense of what "cleaned" means here: `#8266` took seven review rounds and `#8624` five, because each one is a literal-boundary rule and the reviewer legitimately found another boundary every round. I fixed every one of them rather than arguing, and each fix now carries a test that fails without it. **The specific ask, and why it is this one.** The request in the title — allowlisting active contributors — is the right lever, not because I want a badge, but because of what the two contributors who already have write access do with it: `kaoru0822-kitauji` (12 of the last 20 merges) and `gensokyo-dev` (3) merge their own verified work. That is the model I am asking to be held to. If I can merge my own green PRs, those 11 land in one pass and I start the next batch the same hour instead of waiting for a review window. **What I am not asking for.** Not merge rights on anyone else's PR, not a bypass of the review gate, not the ability to merge something with an open finding. The commitment would be the same one I have kept for all 23 merged PRs: nothing merged while a review finding is unanswered, nothing merged without a red/green regression, and the full suite green on the exact commit being merged. **The bar question, stated plainly.** I asked this before and I will ask it once, concretely, rather than guessing: if the bar is not "merged-PR count plus a clean review record", tell me what it is. My record is 23 merged, every open PR green and review-clean, two of them resolving issues you filed this month. If that is not the bar, I genuinely do not know what is, and I would rather be told "no, and here is why" than keep inferring it. If you would rather discuss this on Discord, that is fine too — you mentioned finding you there. But I wanted the reasoning and the numbers on the record in this thread, since this is where the last decision was made.

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

codex/procedure-reference-stacked

release-please--branches--main--components--rea-agents

release-please--branches--main--components--rea-agents--release-notes

codex/kuna-independent-retry

codex/byte-search-overlay-coverage

codex/open-failure-target-receipt

codex/kuna-xref-evidence

codex/ghidra-ambiguous-procedure-recovery

codex/function-source-bundle

codex/trace-function-integration-prototype

codex/snapshot-source-closure

codex/recorded-evidence-array-pages

codex/evidence-recovery-redesign

codex/trace-feature-address-scope

codex/call-discovery-scope

codex/ghidra-literal-candidate-evidence

codex/decompile-directory-independent-retry

codex/retry-provenance-base

codex/value-flow-capability-experiment

codex/ghidra-containing-instruction

cursor/readme-discord-button-ef9f

dependabot/github_actions/actions/setup-node-7.1.0

dependabot/github_actions/actions/upload-artifact-7.0.2

dependabot/npm_and_yarn/npm-minor-and-patch-d8d97ce6df

codex/kuna-1989

fix/8559-native-ui-fixture-ownership

fix/8555-go-verifier-mcp-ownership

codex/provider-capability-recovery

fix/8642-rizin-target-stdin

codex/ghidra-memory-effect-scope

codex/ghidra-annotation-entry-selector

codex/ghidra-readonly-recovery

codex/ghidra-regex-verifier-recovery

codex/evidence-discovery-view-guidance

fix/8545-bulk-append-overflow

fix/8428-navigation-refusal-alternatives

codex/address-context-recovery

codex/matching-member-limitations

codex/unknown-scope-contract

codex/evidence-view-guidance

feat/8373-native-trace-views

codex/ghidra-snapshot-verifier-binding

codex/elf-export-visibility

codex/evidence-view-recovery

codex/native-reference-cli-help

codex/provider-candidate-observation-scope

codex/kuna-session-verification

codex/ghidra-switch-lifetime-guidance

codex/pseudocode-paging-discovery

codex/clarify-evidence-view-support

codex/kuna-xrefs-selector-recovery

codex/context-capacity-recovery

codex/evidence-closure-large-links

codex/same-function-evidence-identity

codex/ghidra-verifier-inspected-jdk

codex/audit-guided-workflows

codex/crash-prompt-retained-dossiers

codex/analysis-view-error-recovery

codex/kuna-verifier-target-selection

codex/ghidra-selected-project-call-coverage

codex/docs-native-analysis-scope

codex/ghidra-java-socket-boundary

codex/ghidra-retained-snapshot-verifier

codex/ghidra-search-inventory-facts

fix/8284-zero-argument-parameter-bindings

fix/8198-ui-action-handler-offset

fix/8257-elf-entry-label-identity

fix/8304-deferred-output-schema-projection

fix/8277-call-path-computed-target-uncertainty

fix/pr-8089-conflicts

fix/ci-static-duplicate-export

dependabot/npm_and_yarn/lint-staged-17.6.0

dependabot/github_actions/actions/download-artifact-8.0.2

dependabot/npm_and_yarn/write-file-atomic-8.0.0

dependabot/npm_and_yarn/canonicalize-5.1.0

dependabot/github_actions/actions/cache/restore-6.1.0

dependabot/npm_and_yarn/toon-format/toon-4.4.0

dependabot/github_actions/actions/deploy-pages-5.0.1

codex/review-fixes-pr-2403

codex/review-fixes-pr-2400

codex/process-terminal-width

codex/test-brittleness-cleanup

verify/7167-browser-connect-macos

fix/7167-browser-connect

feat/native-matching-allowance-setting

feat/browser-scenario-dry-run

test/managed-caller-parameters-20261024

codex/parser-fortythird-boundaries

fix/6926-pinvoke-platform-decorations-20261023

fix/6889-har-body-encoding-20261023

fix/6888-sqlite-schema-budget-20261023

fix/dependency-security-gates-6708

cursor/evidence-overwrite-rebase-b4ac

feat/4057-verify-native-exports

fix/windows-acl-observer-overhead-20261022

cursor/erlang-beam-restack-4476

cursor/pe-certificate-review-bf32

fix/6116-javascript-application-fs-errors

fix/6061-unmapped-runtime-script-unknown

feat/browser-scenario-summary

fix/pe-certificates

codex/verify-3407

cursor/rebase-5699

cursor/rebase-5352

cursor/rebase-5600

cursor/fix-cli-schema-omission-10a8

codex/audit-hopper-shutdown-reasons-20261021

fix/demangle-swift-omitted-record

fix/nib-boolean-value-types

cursor/cancellation-partial-observation-a5ac

fix/ib-object-limit-reasons

fix/electron-fuse-limit-advice

fix/kuna-doctor-dangling-cache

fix/fixed-budget-refusal-advice

fix/js-ipc-listener-dedup

fix/js-return-member-provenance

fix/dmg-integrity-retry-advice

fix/ida-doctor-readiness

fix/kuna-version-probe-output-drain

fix/legacy-swift-runtime-name-matching

fix/dylib-lazy-load-commands

fix/browser-scenario-startup-cancel

fix/swift-nested-punycode-classification

fix/compare-unselected-scopes

fix/objc-method-budget-coverage

fix/dmg-mounted-root-observations

audit/ci-tests-20261019-round2

release/6.7.0

fix/wabt-cleanup-retry-resolution

fix/electron-fuse-elf-pe-architecture

fix/native-plist-descriptor-ownership

fix/kuna-caller-cleanup-ownership

experiment/atomic-codemode-20261016

review/first-contributor-3776

fix/call-resolution-full-read-cycles

fix/member-mutation-selection-repeat

experiment/atomic-re-tools-20261015

perf/member-mutation-lazy-origins

perf/static-network-mutation-index

fix/hopper-startup-lifecycle

audit/3050-windows-proof-20261015

feat/windows-window-capture-2183

audit/3049-windows-proof-20261015

audit/3735-macos-fixtures-20261015

fix/batch-decompile-null-pseudocode

fix/kuna-inventory-honors-jobs

experiment/browser-codemode-tool-design-20261015

fix/hopper-clean-runtime-argv

codex/review-2049-27f1b367

review-fixes/pr-2787-routing

fix/3360-scoped-this-emitters

fix/3367-replaced-global-effects

fix/3838-compact-any-value-items

test/hopper-download-probe-20261015

codex/windows-runtime-creation-red-green-20261015

codex/windows-readonly-root-red-green-20261015

codex/windows-root-share-red-green-20261015

codex/exp-1685-win-mcp-startup

codex/bug-sweep-20261015

investigate/2190-windows-package-phases

investigate/3543-macos-cli-deadline

perf/3281-reverse-tools-feedback-quality

fix/3406-hopper-doctor-fixture

fix/3341-wrapper-require-test-context

fix/3301-owned-uninstall-fixtures

fix/3164-compiler-input-ownership

fix/pcap-cleanup-stdout-newline-20261014

perf/interface-builder-summary

codex/review-fixes-pr-1977

fix/ghidra-effective-jvm-platform

fix/docs-turkish-rust-link-20261013

fix/main-maintenance-ci-20261010

fix/recover-binary-session-process-effects

codex/review-fixes-pr-2457

codex/ci-required-cancellation-gate

fix/main-format-baseline-20261013

fix/setup-preserve-entry-fields

cursor/restore-main-checks-1ffc

fix/ghidra-bridge-hashmap-import

codex/shared-ci-jadx-json-default-20261013

codex/shared-ci-ghidra-test-groups-20261013

codex/shared-ci-java-fixture-format-20261013

codex/fix-intrinsic-invocation-boundaries

test/release-preflight-reusable-jobs

test/js-parameter-provenance-expectation

fix/linux-hopper-verification-current

test/2419-ghidra-elf-probe-size

followup/pr-1544-native-ida

codex/fold-pr-2230-contribution

docs/readme-responsible-use

fix/issue-2064

fix/issue-2050

fix/issue-2053

fix/issue-1968

fix/issue-1945

experiment/codemode-bridge-20261011

fix/tool-effects-negative-wording-1904-20261012

fix/1842-electron-interop-provenance

feat/recover-javascript-multi-input

refactor/website-i18n-prep

fix/nativeaot-pe-virtual-extent

fix/browser-verifier-ci-hang

fix/pe-resources-input-selection

docs/beginner-friendly-guides

docs/beginner-setup-guide

fix/javascript-analysis-worker-1563

fix/1649-ghidra-duplicate-names

fix/javascript-export-keys-integration-1369

test/maintenance-boundary-contracts-20261011

review/javascript-export-keys-1369

review/process-live-progress-1483

test/javascript-1495-growth-ratio

fix/ci-escape-timing

docs/normalized-terminal-geometry-1450

release/6.3.0

archive/release-6.3.0-pr1381

release/6.2.0

fix/electron-preload-dynamic-override

fix/javascript-self-referential-bundler-edges

release/6.1.0

cursor/grok-client-cherry-pick-0b56

feat/signature-posture

feat/dyld-shared-cache

feat/artifact-integrity-policy

feat/pkg-inventory

release/6.0.0

chore/sync-release-5.0.0

release/5.0.0

cursor/cloud-agent-node-787e

fix/javascript-xhr-open-endpoints

review/pr-711-realpath-fallback-wording

cleanup/replay-confinement

codex/test-suite-performance

codex/issue-foundations

codex/address-open-issues-2026-07-20

agent/javascript-vite-rollup-esbuild-adapters

agent/process-cleanup

agent/triage-integration

agent/unknown-commands-registry

feat/mcp-identity-metadata

morlvps/issue_cleanup

codex/installer-redesign

morl/roadmap-investigation-core

morl/roadmap-investigation-docs

release-please--branches--main--components--rea

rea-agents-6.8.0

rea-agents-6.7.0

rea-agents-6.6.0

experiment/atomic-codemode-wait-runtime-20261016

rea-agents-6.5.0

rea-agents-6.4.0

rea-agents-6.3.0

rea-agents-6.2.0

rea-agents-6.1.0

rea-agents-6.0.0

rea-agents-5.0.0

rea-agents-4.1.0

rea-agents-4.0.1

rea-agents-4.0.0

rea-agents-3.2.1

rea-agents-3.2.0

rea-agents-3.1.0

rea-agents-3.0.0

rea-agents-2.7.0

rea-agents-2.6.0

rea-agents-2.5.1

rea-agents-2.5.0

rea-agents-2.4.0

rea-agents-2.3.0

rea-agents-2.2.0

rea-agents-2.1.0

rea-agents-2.0.0

rea-agents-1.7.0

rea-agents-1.6.0

rea-agents-1.5.0

rea-agents-1.4.0

rea-agents-1.3.0

rea-agents-1.2.0

rea-agents-1.1.0

rea-agents-1.0.0

rea-agents-0.5.0

rea-agents-0.4.0

rea-agents-0.3.0

rea-0.2.1

rea-0.2.0

Labels

Clear labels   

area: bridge

  

area: bridge

  

area: build

  

area: build

  

area: build

  

area: cli

  

area: domain

  

area: evidence

  

area: mcp

  

area: native

  

area: providers

  

area: runtime

  

area: server

  

area: setup

  

area: tests

  

bug

  

design

  

documentation

  

enhancement

  

enhancement

  

enhancement

  

experiment

  

help wanted

  

i18n

  

invalid

  

P0: critical

  

P1: high

  

P2: medium

  

P2: medium

  

P2: medium

  

P3: low

  

performance

  

provider-request

  

pull-request

Mirrored from GitHub Pull Request

  

question

  

roadmap

  

triage

No labels

area: bridge

area: bridge

area: build

area: build

area: build

area: cli

area: domain

area: evidence

area: mcp

area: native

area: providers

area: runtime

area: server

area: setup

area: tests

bug

design

documentation

enhancement

enhancement

enhancement

experiment

help wanted

i18n

invalid

P0: critical

P1: high

P2: medium

P2: medium

P2: medium

P3: low

performance

provider-request

pull-request

question

roadmap

triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#1285

No description provided.