Question: supporting additional ChatGPT tools in browser mode

[DragonFSKY]

Question

Oracle already supports activating Deep Research through ChatGPT's composer tools menu.

I was wondering whether it might be useful for browser mode to support other tools or connectors exposed by ChatGPT, such as Web Search, Canvas, or connected apps.

I may be overlooking some constraints here, and I am not sure whether this belongs within Oracle's scope. One possible direction could be a small shared mechanism for selecting and verifying tools already available in the signed-in ChatGPT UI, while capabilities with special lifecycles, such as Deep Research, would keep their own handling.

Would this direction be useful, or would separate capability-specific options be a better fit?

If there is interest, I would be happy to investigate the current UI and put together a small proof of concept. No worries at all if this is something Oracle would prefer to keep out of scope.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 12, 2026, 6:16 AM ET / 10:16 UTC.

Summary
Keep open for a maintainer product decision. Browser mode deliberately has a specialized Deep Research contract; expanding it to Web Search, Canvas, or connected apps needs an explicitly supported capability and account-behavior boundary first.

Reproducibility: not applicable. this requests new browser-mode capability rather than reporting broken existing behavior.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.

Maintainer decision needed

Question	Recommendation
Which ChatGPT composer capabilities, if any, should Oracle support as durable browser-mode contracts beyond Deep Research?	Keep the current narrow scope: Retain Deep Research as the only composer-tool integration until a concrete capability has a compelling Oracle workflow and stable verification path.

Why: Current code and docs establish a dedicated Deep Research lifecycle, but neither defines a generic tool registry nor a supported contract for Web Search, Canvas, or connected apps.

Next step
A maintainer must choose the supported capability set and contract before a bounded implementation exists.

Review details

Best possible solution:

Keep Deep Research capability-specific for now; add another tool only after its activation, confirmation, completion, artifacts, account availability, and failure behavior are specified and proven independently.

Do we have a high-confidence way to reproduce the issue?

Not applicable: this requests new browser-mode capability rather than reporting broken existing behavior.

Is this the best way to solve the issue?

No: implementing a generic selector now would skip the tool-specific lifecycle and account-contract decisions that current Deep Research handling makes explicit.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A generic selector could silently map differently across ChatGPT accounts, plans, locales, and changing UI labels.
• Canvas and connected apps may have different confirmation, output, authorization, and side-effect lifecycles than Deep Research, so menu selection alone is not a safe support contract.

Codex review notes: model internal, reasoning high; reviewed against f5b9c8106cf6.

Label changes

Label justifications:

• P3: This is an optional browser-mode capability proposal with no established broken-behavior contract.

Evidence reviewed

What I checked:

• Current supported scope: The browser configuration exposes a research mode whose documented behavior is specifically Deep Research; the public browser-mode documentation says Deep Research does not use connected apps in v1. (docs/browser-mode.md:174, f5b9c8106cf6)
• Specialized lifecycle: Deep Research bypasses normal thinking-time handling, activates its own composer control before submission, then waits for a research plan and completed research result. (src/browser/index.ts:1500, f5b9c8106cf6)
• Current API boundary: The browser session type defines research mode as the browser-only Deep Research switch; there is no current generic composer-tool selection contract. (src/browser/types.ts:115, f5b9c8106cf6)
• Feature history: History tracing found the Deep Research completion-proof work in commit c630744, reinforcing that this tool has output-specific correctness handling rather than being a generic menu click. (c630744b0d28)
• Related RFC: The linked open RFC RFC: add a native ChatGPT delegation skill and decouple advisory workflow from browser transport #355 concerns a broader transport-neutral advisory architecture; it cites this issue but does not define the per-tool browser automation contract requested here.

Likely related people:

• steipete: Current Deep Research source lines trace to the v0.17.2 release-preparation commit under Peter Steinberger, and this repository’s browser-operation policy is maintained at the root. (role: current browser-mode source contributor; confidence: high; commits: 4bd598962253; files: src/browser/actions/deepResearch.ts, src/browser/index.ts, docs/browser-mode.md)
• Zhongyue Lin: Commit c630744 records completion-proof work on the Deep Research surface, which is central to deciding whether another tool can share its lifecycle. (role: Deep Research completion-path contributor; confidence: medium; commits: c630744b0d28; files: src/browser/actions/deepResearch.ts, tests/browser/deepResearch.test.ts)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.