Skip to content

Make the chat empty-state greeting configurable via CHAT_GREETING#227

Open
noramxiao wants to merge 2 commits into
mainfrom
fix/configurable-greeting
Open

Make the chat empty-state greeting configurable via CHAT_GREETING#227
noramxiao wants to merge 2 commits into
mainfrom
fix/configurable-greeting

Conversation

@noramxiao
Copy link
Copy Markdown

Problem

The empty-state greeting in e2e-chatbot-app-next is hardcoded to "What would you like to know?" in client/src/components/greeting.tsx. Because this frontend is the shared chat UI used by the agent templates, customizing the greeting (a very common ask) currently requires patching the shared frontend instead of simple configuration. Reported in #177.

Change

Surface the greeting through the existing /api/config mechanism (the same one used for feedback/chatHistory flags):

  • server/src/routes/config.ts/api/config now returns greeting: process.env.CHAT_GREETING || undefined.
  • client/src/contexts/AppConfigContext.tsx — adds greeting to the config type/context, defaulting to DEFAULT_GREETING ("What would you like to know?") when unset.
  • client/src/components/greeting.tsx — renders useAppConfig().greeting instead of the hardcoded string.
  • .env.example — documents the new optional CHAT_GREETING var.

Backward compatible: with CHAT_GREETING unset, the UI shows the exact same default as before.

Testing

I could not run npm run lint / npm test in my environment (no network to the npm registry, deps not installed). The change is small and mirrors the existing feedbackEnabled/chatHistoryEnabled config plumbing, but a maintainer should run the Biome lint + Playwright tests before merge.

Out of scope: the chat input placeholder (elements/prompt-input.tsx) uses the same default string — could be wired to CHAT_GREETING too in a follow-up if desired.

Fixes #177

noramxiao added 2 commits May 30, 2026 00:27
The empty-state greeting in e2e-chatbot-app-next was hardcoded to "What would
you like to know?" in greeting.tsx, forcing downstream template users to patch
the shared frontend for a common customization.

Surface it through the existing /api/config mechanism: the server now returns
a `greeting` field sourced from the CHAT_GREETING env var, and the Greeting
component reads it from AppConfigContext, falling back to the previous default
when unset. Documented the new var in .env.example.

Fixes #177

Co-authored-by: Isaac
Verifies /api/config omits greeting when CHAT_GREETING is unset (client falls
back to the default). Part of #177.

Co-authored-by: Isaac
@noramxiao
Copy link
Copy Markdown
Author

Verified locally

Installed deps and ran the toolchain on this branch:

  • Route tests (tests/routes/config.test.ts, TEST_MODE=ephemeral): 8 passed, including a new test asserting /api/config omits greeting when CHAT_GREETING is unset (client falls back to the default).
  • Biome (npx biome check) on the changed files: my added/changed lines are clean. The pre-existing warnings biome reports (class sorting / quote style in greeting.tsx's untouched className, the OBO arrow-fn formatting in config.ts, a destructuring collapse in config.test.ts) are all on lines this PR did not author — the e2e-chatbot-app-next tree has pre-existing biome drift repo-wide (a plain npm run lint auto-fixes 22 unrelated files). I intentionally did not include those cosmetic repo-wide fixes here.
  • Typecheck: errors surfaced by a raw tsc run are all pre-existing/environmental (missing @types/react-syntax-highlighter, unbuilt workspace packages) and none reference the changed files.

So the change is functionally verified (route tests green) without introducing new lint/type violations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Make the initial greeting / empty-state / first assistant message configurable

1 participant