## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies.
> - Company Environments is the operator-facing seam for choosing where
compatible adapters execute work.
> - Sandbox provider plugins such as E2B extend that seam, but they are
not agent adapters themselves.
> - The current Company Environments copy put adapter capability rows
and sandbox-provider enablement on the same page without clearly
distinguishing the two concepts.
> - That made it look like installing the E2B sandbox provider caused a
new adapter to appear under adapters.
> - This pull request clarifies the UI language so provider plugins are
described as backing the Sandbox driver rather than being adapter types.
> - The benefit is a more accurate mental model for operators
configuring environments and adapters.
## What Changed
- Added explicit Company Environments copy stating that installed
sandbox providers are not adapter types and instead back the Sandbox
driver for compatible adapters.
- Renamed the support-matrix column from `Sandbox` to `Sandbox via
plugin` to make the provider relationship visible in the table itself.
- Extended the existing environments UI test to assert the new
clarification text.
## Verification
- `pnpm test -- --run ui/src/pages/CompanySettings.test.tsx`
Result: could not complete cleanly in this worktree because the checkout
is missing its local workspace install links.
- Direct Vitest fallback against `ui/src/pages/CompanySettings.test.tsx`
Result: failed before test collection on local dependency resolution
(`react/jsx-dev-runtime`), so there is no passing automated signal from
this checkout.
- Manual review
Confirm the Company Environments page now says sandbox providers are not
adapter types and labels the table column as `Sandbox via plugin`.
## Risks
- Low risk. This is a copy-only UI clarification plus a matching test
assertion; the main risk is wording drift if the product later decides
sandbox providers should be surfaced differently.
## Model Used
- OpenAI Codex via the local `codex_local` Paperclip adapter. This run
used tool-assisted code editing and shell execution. The exact backend
model ID and context window are not exposed in the Paperclip run context
for this session.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [ ] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [ ] If this change affects the UI, I have included before/after
screenshots
- [ ] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [ ] I will address all Greptile and reviewer comments before
requesting merge
## Thinking Path
> - Paperclip orchestrates AI agents for zero-human companies
> - Agents run inside environments (local, SSH, E2B sandbox)
> - Operators need to configure and manage these environments
> - But environment settings were buried inside the general company
settings page, making them hard to find
> - Additionally, when testing an agent from the configuration form, the
test always ran locally regardless of which environment was selected
> - This PR moves environments into a dedicated top-level company
settings section and wires the "Test Environment" button to run inside
the selected environment
> - The benefit is operators can find and manage environments more
easily, and the test button now validates the actual environment the
agent will use
## What Changed
- Added a dedicated `CompanyEnvironments` settings page with its own
route and sidebar entry
- Updated `CompanySettingsSidebar` and `CompanySettingsNav` to include
the new environments section
- Modified the agent test route (`POST /agents/:id/test`) to accept an
optional `environmentId` parameter
- Updated all adapter `test.ts` handlers to resolve and use the
specified execution target environment
- Added `resolveTestExecutionTarget` to `execution-target.ts` for remote
environment test resolution with cwd fallback
- Moved the "Test Environment" button and its feedback display into the
`NewAgent` page footer for better UX flow
## Verification
- `pnpm test` — all existing and new tests pass
- `pnpm typecheck` — clean
- Manual: navigate to Company Settings, confirm "Environments" appears
as a top-level section
- Manual: configure an agent with a non-local environment, click "Test
Environment", confirm the test runs inside that environment
## Risks
- Low risk. UI-only routing change for the settings page. The
test-in-environment change adds an optional parameter with a local
fallback, so existing behavior is preserved when no environment is
specified.
## Model Used
Codex GPT 5.4 high via Paperclip.
## Checklist
- [x] I have included a thinking path that traces from project context
to this change
- [x] I have specified the model used (with version and capability
details)
- [x] I have checked ROADMAP.md and confirmed this PR does not duplicate
planned core work
- [x] I have run tests locally and they pass
- [x] I have added or updated tests where applicable
- [x] If this change affects the UI, I have included before/after
screenshots
- [x] I have updated relevant documentation to reflect my changes
- [x] I have considered and documented any risks above
- [x] I will address all Greptile and reviewer comments before
requesting merge
Devin Foley