Skip to content

feat: ship inline chat to everyone - #1284

Merged
Nikhil (shadowfax92) merged 1 commit into
mainfrom
feat/ship-inline-chat-everyone
Jun 19, 2026
Merged

Nikhil (shadowfax92) merged 1 commit into
mainfrom
feat/ship-inline-chat-everyone

Conversation

@shadowfax92

Copy link
Copy Markdown
Contributor

Summary

  • Removes the alpha-feature requirement from the new tab home inline chat gate.
  • Keeps NEWTAB_CHAT_SUPPORT as the BrowserOS compatibility boundary.
  • Leaves capability loading and side panel fallback behavior unchanged.

Design

AgentCommandHome already owns the support boolean that feeds resolveHomeLlmRoutingMode. This change narrows that boolean to the real compatibility capability, so supported BrowserOS versions use inline chat without requiring alpha opt-in.

Test plan

  • bun test apps/agent/screens/agent-command/home-compose.helpers.test.ts
  • bun run lint
  • bun run typecheck
  • bun run test:main
  • bun run check
  • bun run build:agent

@shadowfax92

Copy link
Copy Markdown
Contributor Author

Greptile (@greptileai) review

@shadowfax92

Copy link
Copy Markdown
Contributor Author

Claude (@claude) review

@claude

claude Bot commented Jun 19, 2026 •

Copy link
Copy Markdown

Claude finished Nikhil (@shadowfax92)'s task in 1m 37s —— View job


Code Review

  • Gathering context
  • Reading changed files
  • Analyzing diff
  • Providing review feedback

LGTM. This is a clean, minimal feature-ship change. Here's the breakdown:

What changed

AgentCommandHome.tsx:46 — supportsInlineChat used to require both ALPHA_FEATURES_SUPPORT (alpha opt-in flag) and NEWTAB_CHAT_SUPPORT (BrowserOS version gate). The alpha gate is now removed, leaving only the version boundary.

- const supportsInlineChat =
-   supports(Feature.ALPHA_FEATURES_SUPPORT) &&
-   supports(Feature.NEWTAB_CHAT_SUPPORT)
+ const supportsInlineChat = supports(Feature.NEWTAB_CHAT_SUPPORT)

Why it's correct

  1. Right capability boundary. NEWTAB_CHAT_SUPPORT maps to minBrowserOSVersion: '0.40.0.0' in capabilities.ts:78. Users on older BrowserOS get supportsInlineChat = false, which causes resolveHomeLlmRoutingMode to return 'sidepanel' — the correct graceful fallback. No hard failure path.

  2. No dead code introduced. Feature.ALPHA_FEATURES_SUPPORT remains active for other feature gates (ToolbarSettingsCard, etc.) — removing it from this one call site is clean.

  3. Tests don't need to change. resolveHomeLlmRoutingMode already abstracts the routing decision from capability resolution — it just takes supportsInlineChat: boolean. All three routing modes (wait, inline-chat, sidepanel) are covered in the existing test suite; the new logic feeds the same boolean contract.

One thing worth confirming (non-blocking)

NEWTAB_CHAT_SUPPORT requires BrowserOS ≥ 0.40.0.0. Before this lands, it's worth a quick sanity-check that the 0.40.x cutoff represents an acceptable floor across the active install base — this is a product question, not a code issue, but good to have eyes on before shipping to everyone.


@shadowfax92
Nikhil (shadowfax92) merged commit 40831e3 into main Jun 19, 2026
17 of 18 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

✅ Tests passed — 1307/1311

Suite Passed Failed Skipped
✅ agent 197/197 0 0
✅ build 18/18 0 0
✅ eval 91/91 0 0
✅ server-agent 301/301 0 0
✅ server-api 141/141 0 0
✅ server-browser 10/10 0 0
✅ server-integration 10/10 0 0
✅ server-lib 256/257 0 1
✅ server-root 47/50 0 3
✅ server-tools 236/236 0 0

View workflow run

@greptile-apps

greptile-apps Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR removes the ALPHA_FEATURES_SUPPORT requirement from the new-tab home inline-chat gate, shipping the feature to all users on compatible BrowserOS versions (>= 0.40.0.0) without requiring an alpha opt-in.

  • supportsInlineChat now resolves solely from supports(Feature.NEWTAB_CHAT_SUPPORT), dropping the alpha conjunct; the routing logic in resolveHomeLlmRoutingMode and the side-panel fallback path are otherwise unchanged.
  • ALPHA_FEATURES_SUPPORT remains defined in the Feature enum and is still used in other parts of the codebase, so no dead code is introduced by this change.

Confidence Score: 5/5

Safe to merge — a one-line removal of an alpha flag conjunct with no changes to routing logic, side-panel fallback, or capability loading.

The diff removes a single boolean condition. The remaining gate (NEWTAB_CHAT_SUPPORT, gated to BrowserOS >= 0.40.0.0) is already tested and in production for the alpha cohort. Side-panel fallback for older BrowserOS versions is preserved, and ALPHA_FEATURES_SUPPORT continues to function correctly in all other feature contexts.

No files require special attention.

Important Files Changed

Filename Overview
packages/browseros-agent/apps/agent/screens/agent-command/AgentCommandHome.tsx Removes ALPHA_FEATURES_SUPPORT from the supportsInlineChat gate, leaving only the NEWTAB_CHAT_SUPPORT version check (BrowserOS >= 0.40.0.0); logic is correct and minimal.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[User submits prompt] --> B{capabilitiesLoading?}
    B -- yes --> W[mode: wait\ndisable submit]
    B -- no --> C{supports NEWTAB_CHAT_SUPPORT?\nBrowserOS >= 0.40.0.0}
    C -- yes --> D[mode: inline-chat\nnavigate to /home/chat]
    C -- no --> E[mode: sidepanel\nopenSidePanelWithSearch]

    style W fill:#fbbf24,color:#000
    style D fill:#34d399,color:#000
    style E fill:#60a5fa,color:#000
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[User submits prompt] --> B{capabilitiesLoading?}
    B -- yes --> W[mode: wait\ndisable submit]
    B -- no --> C{supports NEWTAB_CHAT_SUPPORT?\nBrowserOS >= 0.40.0.0}
    C -- yes --> D[mode: inline-chat\nnavigate to /home/chat]
    C -- no --> E[mode: sidepanel\nopenSidePanelWithSearch]

    style W fill:#fbbf24,color:#000
    style D fill:#34d399,color:#000
    style E fill:#60a5fa,color:#000
Loading

Reviews (1): Last reviewed commit: "feat: ship inline chat to everyone" | Re-trigger Greptile

@greptile-apps

greptile-apps Bot commented Jun 19, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR ships the new-tab inline chat to all users by removing the ALPHA_FEATURES_SUPPORT guard that previously blocked it. The NEWTAB_CHAT_SUPPORT capability (BrowserOS ≥ 0.40.0.0) remains as the sole compatibility gate, so older browser versions still fall back to the side panel.

  • Gate simplification: supportsInlineChat in AgentCommandHome drops the && with ALPHA_FEATURES_SUPPORT, making NEWTAB_CHAT_SUPPORT the only condition evaluated by resolveHomeLlmRoutingMode.
  • No behavior change for unsupported versions: The resolveHomeLlmRoutingMode helper returns 'sidepanel' when the capability is absent, so the fallback path is unaffected.

Confidence Score: 5/5

Safe to merge — the change is a single boolean simplification with a clear, well-tested fallback path for unsupported BrowserOS versions.

The only modification is dropping the alpha-flag requirement from a capability check. The capability system and routing helpers are unchanged, and the side-panel fallback for users below BrowserOS 0.40.0.0 continues to work exactly as before.

No files require special attention.

Important Files Changed

Filename Overview
packages/browseros-agent/apps/agent/screens/agent-command/AgentCommandHome.tsx Removes ALPHA_FEATURES_SUPPORT from the supportsInlineChat guard, leaving NEWTAB_CHAT_SUPPORT as the sole gate; routing logic is unchanged.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[AgentCommandHome mounts] --> B{capabilitiesLoading?}
    B -- yes --> C[llmRoutingMode = 'wait']
    B -- no --> D{supports NEWTAB_CHAT_SUPPORT?}
    D -- yes --> E[llmRoutingMode = 'inline-chat']
    D -- no --> F[llmRoutingMode = 'sidepanel']
    E --> G[navigate to /home/chat]
    F --> H[openSidePanelWithSearch]
Loading
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[AgentCommandHome mounts] --> B{capabilitiesLoading?}
    B -- yes --> C[llmRoutingMode = 'wait']
    B -- no --> D{supports NEWTAB_CHAT_SUPPORT?}
    D -- yes --> E[llmRoutingMode = 'inline-chat']
    D -- no --> F[llmRoutingMode = 'sidepanel']
    E --> G[navigate to /home/chat]
    F --> H[openSidePanelWithSearch]
Loading

Reviews (2): Last reviewed commit: "feat: ship inline chat to everyone" | Re-trigger Greptile

Vasilev Dmitrii (gHashTag) added a commit to gHashTag/BrowserOS that referenced this pull request Aug 19, 2026
She was completely blocked and said so in the most reassuring words available:
"all 26 candidates look already done". Almost every refusal was
`boundary_taken` - "its files are owned by a live task" - and in four cases the
live task owning them was the one she had opened for that same issue.

A task whose dispatch fails stays `queued`, and nothing in the system ever
looked at `queued`. `reapStalledWorkers` handles `running`; a task created and
never started simply holds its file boundary. Its own issue can then never be
chosen again. That is a deadlock, not idleness, and two of the four frozen
issues were the start of the T27 migration.

"Never dispatched" is read from the runner's record rather than the clock: a
stream that opened leaves `streamOutcome` set and a completed turn leaves
`completedTurns`, and either means the runner took it however long ago. Ten
minutes of grace, which is two autonomy ticks - one tick could be a slot that
was full, which is ordinary backpressure.

Cancelled rather than failed. Nobody failed; the dispatch did not happen, and
`cancelled` says that without accusing a worker that never ran.

Driven in the release. The reaper fired four times - browseros-ai#1281 queued 279 minutes,
browseros-ai#1283 237, browseros-ai#1285 190, browseros-ai#1284 184, none with a turn ever opened - and twenty
seconds later she chose browseros-ai#1284 and started ring 01 herself.

904 e2e checks in 84 scenarios, up from 896.
Vasilev Dmitrii (gHashTag) added a commit to gHashTag/BrowserOS that referenced this pull request Aug 19, 2026
…enty-six

The line she printed when she could not choose:

  All 26 candidate(s) look already done — nothing to choose

The truth, once the reasons were counted rather than assumed:

  Nothing to choose from 26 candidate(s): 16 held by another task,
  7 already has a worker, 1 looks already done, 1 no boundary

One case out of twenty-six, presented as all of them, in the most reassuring
words available. It is the same sentence that hid the queued deadlock for
hours, and fixing that deadlock did not fix the sentence.

The boundary refusal is named too. "Its files are owned by a live task" is
anonymous, and sixteen of those in a row read as a busy swarm - when five of
the holders are tasks escalated to the operator hours ago, sitting in
`awaitingReview` because their send-backs are exhausted and holding their paths
while they wait. It now says which task, in which state, and for how long:

  Skipping browseros-ai#1284: its files are held by gHashTag/trios#1284 (queued, 2m)

A block nobody can attribute is a block nobody clears.

Nothing about the mechanism changed: those five tasks are correctly escalated
and correctly still hold their boundaries - a person has to decide, and a bee
editing the same files meanwhile would collide with work waiting to be
accepted. What changed is that the block is now visible and has a name.

910 e2e checks.
Vasilev Dmitrii (gHashTag) added a commit to gHashTag/BrowserOS that referenced this pull request Aug 19, 2026
…s mine

The reaper I added earlier tonight cancels a task whose dispatch never
happened, which unfroze four issues. It also created a cycle: the next tick
chooses the same issue, dispatch refuses at the end of that tick because the
provider key resolves empty, the task sits queued, ten minutes later the reaper
cancels it again. browseros-ai#1284 and browseros-ai#1285 went round that way through branches r1, r2,
r3, r4, cutting a fresh worktree each round while nothing could possibly start.

A permanent deadlock and a permanent spin are both wrong, and the second was
introduced by the fix for the first. Worth saying plainly rather than filing
under "further improvement".

The key is the condition that makes the whole round pointless, so it belongs
before the choosing rather than after it. `autonomyBlockReason` now refuses the
tick outright:

  Not picking up work: the provider key resolves empty, so nothing could be
  dispatched even if an issue were chosen

Ordering is deliberate and tested. Consent and budget still outrank it - those
are decisions, and a decision outranks a resource - but the key outranks
capacity, because with a full swarm and no key the actionable fact is the key.
The live transport is the only one gated, the same exemption the dispatch
precheck already makes for the harness.

What the diagnostics added an hour ago finally said out loud, and what makes
this the right fix rather than a guess:

  fetchIssueBody.primary_failed | Keychain item not found for ai.browseros.trios
  fetchIssueBody                | HTTP 403
  worker.api_key_unavailable    | API key for zai resolved empty

Neither the GitHub token nor the provider key was reachable in that window. The
authenticated fallback I added is only as good as the token, and there is still
no working second source for either - `~/.trios/config.json` holds both keys
with zero-length values.

915 e2e checks in 87 scenarios, up from 910.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant