feat(plugin): include parent agent context in hook inputs

[ArmirKS]

Issue for this PR

Fixes#15403

Type of change

• New feature

What does this PR do?

This adds parentAgent to the plugin hook inputs that need subagent context.
The main fix here is making sure that value actually survives the full prompt flow, so it reaches tool.execute.before, tool.execute.after, shell.env, chat.params, and chat.headers consistently.
Everything is additive, so existing plugins keep working.

How did you verify your code works?

• added coverage for the new prompt/message shapes
• ran bun test test/plugin/parent-agent.test.ts
• ran bun typecheck in packages/plugin
• ran bun typecheck in packages/opencode

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

[bbo76]

any news for this ?

[bnema]

This is great, one gap though: chat.headers and chat.params in llm.ts don't get parentAgent. The PR adds it to tool.execute.* and shell.env, but the LLM hook inputs still only have agent (the name string).

Adding it would be a small change in llm.ts. parentAgent just needs to flow from StreamInput into the Plugin.trigger("chat.headers", ...) and Plugin.trigger("chat.params", ...) calls. That would let plugins adjust headers or model params based on whether the request comes from a subagent.

[tassiocaique]

any new for this?

[ArmirKS]

Thanks @bnema — I fixed the llm.ts gap you called out. parentAgent now reaches both chat.params and chat.headers, and is carried through subagent flows consistently.

I ran into the same issue while building a plugin on my side, so having this in the hook input makes that kind of runtime handling much simpler.

[ArmirKS]

To give more context on why this matters for plugins: right now if a subagent makes a tool call, the plugin hook only sees the current agent, not who dispatched it. That means any plugin doing delegation policy, same-model-family checks, or audit logging has to build its own tracking layer to figure out the parent-child relationship. The session layer already has this data (parentID in task.ts), this PR just passes it through. Would unblock a lot of plugin governance use cases.

[rekram1-node]

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:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

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.