In the sdk, we have taken in a repo skill for Xingyao to test automations, and it had info on staging, deploy etc. We plan to remove it, but I wanted to give him some space here on this. Ah, if custom / user marketplaces for plugins work now, we could maybe remove it assuming it’s possible to use a definition to get it back as needed.

I searched agent-facing skill/context text only:

AGENTS.md

,

SKILL.md

, and

.agents/skills/*

. OpenHands/extensions • skills/openhands-automation/SKILL.md#L53 “This ensures the correct host is used for the deployment environment (e.g.,

<https://staging.all-hands.dev>

for staging,

<https://app.all-hands.dev>

for production).” • Duplicate copy of the same text also exists at plugins/openhands/skills/openhands-automation/SKILL.md#L53 OpenHands/agent-canvas • AGENTS.md#L448 Mentions “staging PostHog key” and that PR/main images use the staging key while release images use the production key. OpenHands/software-agent-sdk All matches I found are in one repo skill: • .agents/skills/cross-repo-testing/SKILL.md#L3 Skill description includes “deploy a feature branch to staging” and “validation against a staging deployment”. • #L16 Refers to deploy repo handling “staging/production”. • #L60 “Deploy the server PR to staging” • #L62 “Deploying to a Staging Feature Environment” • #L64 “Run the SDK e2e test against staging” • #L66 “Running E2E Tests Against Staging” • #L115 Again points to staging feature environment deployment. • #L123 Section header: “Deploying to a Staging Feature Environment” • #L150 Example URL:

<https://ohpr>-<PR>-<random>.staging.all-hands.dev

• #L155 Healthcheck against

...staging.all-hands.dev/api/v1/health

• #L159 Section header: “Running E2E Tests Against Staging” • #L166

STAGING = "<https://ohpr>-<PR>-<random>.staging.all-hands.dev"

• #L169

cloud_api_url=STAGING

• #L181

OPENHANDS_CLOUD_API_URL="<https://ohpr>-<PR>-<random>.staging.all-hands.dev"

The

agent-canvas

occurrence is not about telling the agent to use a staging automation server. It’s this note in `AGENTS.md`: • the Docker image bundles: ◦ agent-server ◦ automation server ◦ agent-canvas frontend • and, separately, the frontend build uses

VITE_APP_ENV

to choose which PostHog telemetry key gets baked into the static bundle. From the actual code: • docker/Dockerfile: default

VITE_APP_ENV=""

• src/services/telemetry.ts: if

VITE_APP_ENV === "production"

, use prod PostHog key; otherwise use staging PostHog key • .github/workflows/docker.yml: CI sets

VITE_APP_ENV=production

only for tagged releases • package.json:

build:lib

also forces

VITE_APP_ENV=production

So the meaning is: • release builds → production analytics key • PR/main/local Docker builds → staging analytics key That AGENTS entry is just documenting that behavior for future agents/humans. If you remove it If you remove it only from AGENTS.md Probably fine. Effect: • no runtime behavior changes • no build behavior changes • no analytics behavior changes • agents just won’t be preloaded with this staging/PostHog context anymore That seems aligned with your goal if you want to stop repo-context from nudging agents toward “staging”-ish thinking. The downside is only loss of useful maintenance context: • a future agent might not realize why non-release Docker images use a different telemetry key • someone debugging analytics behavior may have to rediscover it from code If you remove the underlying staging behavior from code That’s a different decision. Today, staging exists to keep non-release/dev/PR traffic out of production analytics. If you removed that code path and made everything production: • PR builds • main-branch images • local Docker builds would all report into prod PostHog unless telemetry is otherwise disabled/overridden. That would likely pollute production analytics. If instead you removed the fallback entirely and required explicit config: • non-release builds might send no analytics by default • that may be acceptable, but it changes current behavior Bottom line The

agent-canvas

hit is a telemetry/build-config note, not a staging-server instruction. So: • removing the

AGENTS.md

mention: low risk, probably good if your goal is to reduce accidental staging context • removing the actual code behavior: higher-impact product/analytics decision If you want, I can also tell you which of the

software-agent-sdk

occurrences look most likely to be the ones actually biasing the agent toward staging.

Done. PR: • https://github.com/OpenHands/agent-canvas/pull/686 What I changed in `agent-canvas`: • removed the staging PostHog fallback from src/services/telemetry.ts • removed

VITE_APP_ENV

wiring from: ◦ docker/Dockerfile ◦ .github/workflows/docker.yml ◦ package.json ◦ .env.sample • removed the staging/PostHog note from AGENTS.md Validation: • I did lightweight validation only: reviewed the diff, checked for leftover

VITE_APP_ENV

references, and ran

git diff --check

• I did not run the full app/test suite in this environment Then I cloned

OpenHands-CLI

and

OpenHands/OpenHands

and checked for similar PostHog patterns. OpenHands-CLI Relevant hit: • openhands_cli/tui/utils/critic/feedback.py What it does: • uses a single hardcoded PostHog API key • uses a single hardcoded host:

<https://us.i.posthog.com>

• I did not find staging-vs-production key switching like

agent-canvas

had OpenHands/OpenHands Relevant hits: • OSS fallback key: ◦ openhands/app_server/web_client/default_web_client_config_injector.py ◦ openhands/app_server/server_config/server_config.py • frontend gets key from config: ◦ frontend/src/components/providers/posthog-wrapper.tsx • staging/feature env analytics isolation: ◦ openhands/analytics/analytics_service.py • docs mention staging PostHog dashboards: ◦ openhands/analytics/EVENTS.md What it does: • frontend uses one

posthog_client_key

from server config • server uses

POSTHOG_CLIENT_KEY

from env, or a single OSS default fallback key • backend analytics knows about feature/staging envs, but for distinct ID prefixing / isolation, not for selecting between two baked frontend keys • I did not find the same build-time “prod key vs staging key depending on env” pattern there either Bottom line No, in the repos I checked, I did not find another repo doing the same thing

agent-canvas

was doing. What I found instead: • `OpenHands-CLI`: one hardcoded PostHog key • `OpenHands/OpenHands`: one env-provided-or-fallback key, plus feature/staging traffic isolation in analytics • only

agent-canvas

had that specific dual-key, build-time selection pattern based on

VITE_APP_ENV

Yep — I simplified it and pushed the update to the same PR. PR: • https://github.com/OpenHands/agent-canvas/pull/686 What changed: • removed the extra

OPENHANDS_POSTHOG_API_KEY

constant • inlined the single default key directly into

POSTHOG_API_KEY

File updated: • src/services/telemetry.ts Commit pushed: •

9a3dee5

-

Inline default PostHog key

So now it’s just one variable for one effective key path: • override via

VITE_POSTHOG_API_KEY

, else • use the single hardcoded default key If you want, I can keep iterating on this existing PR, or leave it as-is.