README.md

# Daybreak Defense Factory

Daybreak Defense Factory, previously called Codex Security Cloud, delivers the
Aardvark workflows UI through a first-party plugin. Its optional desktop MCP
server comes from the upstream Codex Security SDK.

For internal operational investigations, use the
[Daybreak troubleshooting guide](../../../../api/aardvark/docs/troubleshooting.md)
or the repository's
[`codex-security-cloud-troubleshoot` skill](../../../../skills/skills/codex-security-cloud-troubleshoot/SKILL.md).
The guide covers app/access, API, scan execution, results, and cleanup issues.

## Local MCP server

The hosted `defense-factory` connector serves cloud operations. The desktop
package carries the upstream Codex Security runtime. Daybreak's native
standard, diff, and deep scan skills load their workflows and references
from that verified bundle.

The desktop host and scan conversations use the same `daybreak-local` server.
It is disabled by default. Desktop requests enable only the findings or
scan-management tools they need. Scan conversations enable only workflow tools,
and the launcher marks desktop tools as app-only. Scans and findings use local
Codex Security state. Use a disposable Codex home and state directory for
integration tests.

To refresh the bundle on Linux, download the pinned `@openai/codex-security`
release tarball from the npm registry. Pass it to
`bash chatgpt/oai-maintained-plugins/scripts/csc-desktop-sdk/build.sh <tarball>`
from the repository root. The script verifies the tarball's integrity and packages
its bundled Local MCP. Update the recorded blob hash and launcher digest together.

## Delivery

- `.codex-plugin/plugin.json`, `.app.json`, `assets/`, and `skills/` define the
  installable plugin and its required `connector_openai_defense_factory` app.
- `.internal/defense-factory-ui/src/` owns the UI. The
  [managed build](../../../../api/sheep/packs/defense_factory/defense-factory-ui/README.md)
  bundles its internal platform UI kit and other dependencies into one HTML file.
- The [Sheep pack](../../../../api/sheep/packs/defense_factory/README.md) serves
  `ui://defense-factory/workflows.html`, opened by `open_defense_factory`, and
  implements the signed `defense_factory_*` backend operations.

Build from the monorepo root:

```sh
bazel build //api/sheep/packs/defense_factory/defense-factory-ui:cloud_html
bazel test //api/sheep/packs/defense_factory/defense-factory-ui:resource_test
```

This directory is the release source in the
[maintained catalog](../../docs/maintainer-guide.md). It is `INTERNAL_ONLY`,
targeted to Codex, requires app authentication at installation, and preserves
the `chatgpt-aardvark-workflows` Statsig requirement. The catalog adds no plan
restriction; the app continues to evaluate the caller's existing access.

The catalog entry describes the intended release policy; merging it does not
create a directory record or publish a release. Use the maintained catalog
publication and installation flow for this directory, with restricted internal
visibility and verified stored access policy. Staging records are separate from
production registration. Building the HTML does not register the connector,
deploy Sheep, or install the plugin. The hosted app runs independently of the
optional desktop MCP server.

## Host and access requirements

The host supplies login and workspace selection. The first-party Daybreak bridge
provides GitHub setup and the Cloud environment editor.
Credentials stay outside the plugin iframe. Sheep carries the signed caller to
the existing workspace, Cloud and Aardvark permission checks; installing the
plugin grants none of those permissions.

The internal pack name `defense_factory`, `defense_factory_*` protocol, and existing
permission names remain unchanged. Daybreak owns its onboarding; it does
not read or write the legacy CSC announcement or research-preview agreement.
The versioned introduction preference uses existing account-member settings. An
unseen introduction opens first-scan setup when no scans, configurations or findings
are visible, or a welcome dialog for existing users. Disconnected users connect
GitHub before that discovery; failed reads never imply an empty workspace. Direct
links remain usable. Members can open Findings from the welcome dialog.

First-scan setup shares the normal scan form, backend workflow choices, environment
creation and retry identity. An accepted launch opens the existing progress/results
page. Successful completion offers the existing commit-monitoring setup. Dismissing
the welcome dialog or skipping setup is persisted independently of scan execution. Preference
write failures remain visible and retryable without blocking findings or scans.

Local installed-plugin tests with signed staging backend reads do not establish
a shared staging rollout or production readiness. Fresh OAuth, successful scan
execution, full UI parity and production access require separate validation.