Chat interface

The in-app chat composer is more than a text box. This page covers the surface features that shape how a turn is scoped and how its results are shown: pinning a repository/environment to the conversation, Code mode's durable sandbox, slash commands, the generative UI card registry, and the citation strip that grounds an answer in the knowledge graph.

Pinning repo + environment context

A persistent context bar sits directly above the composer, letting you choose a connected GitHub repository and a workspace environment and pin them to the conversation. Once pinned, the assistant knows which repo/environment you mean on every future turn in that conversation — you don't have to repeat "in the billing repo" on every message.

• The repo and environment selections are independent; pin one, both, or neither.
• Pinning is optional. It only matters for repo-scoped tools (repo.pr.get, repo.ci.status, repo.pr.diff, …) and the /pr, /diff, /ci slash commands below — if nothing is pinned and a command needs a repo, the assistant asks you to pin one rather than guessing.
• The context bar and Code mode are mutually exclusive in the composer: the lightweight pin bar shows when Code mode is off, the fuller Code mode toolbar shows when it's on. They share the same underlying repo/environment selection state.

Code mode

Turning on the composer's Code toggle switches the turn from a chat question into a real repository edit, backed by a durable sandbox (ModalSandboxWorkspace) rather than the ephemeral, ad-hoc sandbox used by agent.code.execute.

• Turning Code mode on renders the agent toolbar (repo + environment pickers) above the composer. The environment auto-defaults to the workspace's default environment; the repository does not.
• Both a repository and an environment must be selected before you can send. Until then, send is disabled and the composer shows "Select a repository and environment to start coding." The toggle itself is disabled when the workspace has no connected repositories.
• Once both are chosen, the sandbox clones the selected repo (idempotently — reusing a warm sandbox keyed by workspace + conversation + connection when one already exists) and injects the selected environment's vault secrets for builds/tests. Secrets are never printed, echoed into files, or committed by the agent.
• With a bound repository, the agent gets a different system prompt layered over the standard chat baseline: it is told to locate before touching code (code_graph, grep/glob before guessing paths), read a file before editing it, make the smallest correct change, verify with the project's own build/test/lint commands via bash, and cite path:line locations rather than dumping raw tool output into the reply.
• The deterministic structured tools (test_unit_run, build_package_run, git_diff_summarize, workspace_health_check) are available in Code mode alongside the filesystem/exec primitives, so the agent verifies its own edits with typed, bounded tool output instead of parsing raw command scrollback.

Code mode is a different mechanism from the ad-hoc agent.code.execute sandbox: agent.code.execute runs a single snippet in an ephemeral, torn-down-after-use sandbox with no repository context; Code mode binds a whole turn's filesystem/exec tools to a real, checked-out repository in a session-reusable sandbox.

Slash commands

Typing / in the composer opens an autocomplete menu of slash commands. A slash command is not a hard client-side router — the composer sends the literal text (e.g. /ci main) and the agent, told about each command in its system prompt, maps it to the right capability. The one exception is /pin, which the composer intercepts and handles locally.

The /pr, /diff, and /ci commands act on whichever repository is pinned to the conversation — if nothing is pinned, the assistant asks you to pin one instead of guessing.

Generative UI cards

Tool results that benefit from a purpose-built view render as cards instead of plain text — the model returns structured output (generateObject) and the client maps the component type to a React renderer from a shared card registry, never a server-rendered tree. Cards relevant to the chat surfaces above include:

These sit alongside the approval, plan, memory-recall, and background-task cards already covered elsewhere — see Tools and capabilities for the tool surface that produces them.

Graph-grounded citations

When a turn recalls workspace memories to ground its answer, the chat surfaces a "Grounded in" citation strip beneath the assistant's response — concrete proof of which knowledge-graph facts backed the answer, not just an unverifiable claim.

• Each recalled memory is cited by the knowledge-graph node it is about, using the shared NodeRef chip: a colour-coded label, a hover/click property popover, and a copyable id — never a bare UUID, matching the same citation convention used everywhere else a node or edge is referenced in the UI.
• Each citation includes a "View in graph" deep link that opens the graph explorer focused on that exact node (?focus=<publicId>), so a cited fact is one click from its live graph context.
• Recall runs concurrently with the model's turn, best-effort — resolving citations never delays the first streamed token, and the strip persists across a page refresh (it's stored as a message content block, not recomputed each render).

This is the concrete, inspectable half of Oxagen's graph-grounding story: an answer that cites a fact links you to the exact node and edge that produced it, not just a paragraph of prose.