| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Sorry, something went wrong.
|
The following comment was made by an LLM, it may be inaccurate: Potential Related PRs FoundNote: These are related to the same problem space (nested subagent permission prompts), but most appear to be older attempts or adjacent features. Current PR #36046 seems to be a new fix for this recurring issue.
The current PR (#36046) appears to be addressing a recurring issue with nested subagent permission visibility. #30639 and #24638 are the most directly related, as they target the same root cause. You may want to verify if this is a re-fix of a previously closed issue or if those older PRs had different approaches. |
Sorry, something went wrong.
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
Sorry, something went wrong.
Ported from upstream anomalyco#36046.
Ported from upstream anomalyco#36046.
Nested subagents (subagent spawning a subagent) could trigger a permission request that was never rendered in the UI, deadlocking the whole call chain. The TUI and CLI only tracked direct child sessions, so grandchild session events were silently dropped. - tui: collect the full session subtree (not just direct children) when gathering pending permissions/questions - opencode: bootstrap the CLI subagent footer with all descendants via a level-by-level BFS instead of only direct children - opencode: register grandchild tabs when a known child session spawns a nested task, without skipping the child's own event tracking - app: add regression coverage confirming auto-accept rules already propagate correctly across a three-level session chain Signed-off-by: huangzhibin1 <huangzhibin1@xiaomi.com>
|
I reviewed this alongside the other implementations linked from #13715. This PR is the closest current implementation of the model already used by the web/desktop app: preserve the nested request’s actual session and make the TUI/headless clients aware of the complete session subtree. I added a coordination comment to #13715 asking maintainers to clarify whether this is the intended long-term architecture, or whether core should instead expose a separate root/presentation owner for nested blockers. My preference is:
The TUI traversal in this PR remains a valid and low-risk fix for the current deadlock. The architectural question is whether the same traversal should continue to be duplicated across clients or move behind a shared core contract. |
Sorry, something went wrong.
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Sorry, something went wrong.
|
41496 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Issue for this PR
Closes #13715
Type of change
What does this PR do?
Nested subagents (a subagent spawning its own subagent) could trigger a permission request that was never rendered in the UI, deadlocking the whole call chain. The TUI and CLI only tracked direct child sessions, so grandchild session events were silently dropped and the user had no way to approve the pending permission.
Root cause: both the TUI's permission collection and the CLI's subagent footer only looked one level deep in the session tree (direct children), instead of the full subtree. The permission events themselves were delivered correctly (SSE broadcast is not session-scoped) — the gap was purely in how the UI/CLI decided which sessions to display.
Changes:
How did you verify your code works?
Screenshots / recordings
N/A — this fixes visibility of an existing permission prompt for deeper session nesting; no new UI surface.
Checklist