Skip to content
Academy Menu

Connecting Copilot to Dailybot

Step-by-step setup to connect GitHub Copilot activity to Dailybot’s agent reporting so completions and session signals show in your team timeline.

guide Developer 5 min read

GitHub Copilot helps engineers move faster inside the editor. Dailybot helps teams see work in motion—especially when coding agents contribute alongside people. Connecting the two closes the gap between Copilot-assisted sessions and the standup-style visibility your org already trusts.

This guide walks through prerequisites, enabling the integration, choosing what Copilot may report, and verifying entries in your Dailybot timeline.

Prerequisites

Before you start, line up the following:

  • Dailybot workspace where you can install or approve integrations (admin or equivalent).
  • GitHub Copilot access for the developers who should appear in reporting—either a paid seat or org-managed Copilot policy.
  • Supported editor with Copilot signed in to the same GitHub identity you will map in Dailybot.
  • Network path from the developer machine (or your approved relay) to Dailybot’s APIs over HTTPS; corporate proxies should allow the documented endpoints.

If you also use the Dailybot CLI for other agents, keep Copilot on the same workspace so timelines stay consistent.

Enable the Copilot integration

  1. Sign in to Dailybot and open Integrations (or your workspace Settings → Integrations area, depending on your layout).
  2. Find GitHub Copilot (or Copilot / IDE agent reporting) and choose Connect or Configure.
  3. Complete OAuth or token-based steps as prompted. Prefer organization-level approval so every seat does not repeat the same consent flow.
  4. Select the workspace and team that should receive Copilot signals. Smaller teams often start with one engineering squad before rolling wider.

After connection, Dailybot can accept structured activity from Copilot-related tooling. If your org uses a managed device policy, allow the integration’s client or relay through endpoint protection.

Copilot-specific setup in the IDE

Copilot runs inside the editor, not as a separate daemon. In practice you will:

  • Ensure Copilot is signed in and completions are enabled for the repository you care about.
  • If Dailybot ships an editor companion or relay for Copilot, install it from the marketplace or internal bundle your admin provides, then sign in with the same Dailybot workspace.
  • For teams that standardize on CLI-based reporting alongside Copilot, keep agent_scripts/dailybot-report.sh (or your equivalent) in the repo root and document when humans or automation should emit a manual report versus relying on Copilot telemetry.

Match the GitHub account in the editor to the identity you authorized in Dailybot so events are not dropped as “unknown user.”

Configure what Copilot reports

Balance transparency with noise. In the integration settings, you typically choose among:

  • Code completions and inline suggestions — high-level counts or categories, not necessarily full code bodies.
  • Accepted suggestions — signals that a suggestion was adopted, useful for understanding where Copilot changed outcomes.
  • Session activity — session start/end or heartbeat-style markers so long Copilot-assisted work does not look invisible.

Use sampling or thresholds if available (for example, only report sessions longer than a few minutes, or batch events every hour). Align those rules with how you treat other agents like Cursor or Claude Code so the feed stays fair.

How reports appear in the Dailybot timeline

Copilot-sourced entries land in the same chronological timeline as check-ins and other agent posts. Expect:

  • Source labels such as “Copilot” or “GitHub Copilot” so readers can filter mentally.
  • Metadata like repository, branch, or editor type when the integration provides it.
  • Correlation next to human updates—useful when someone writes “shipped the API change” and Copilot shows a dense suggestion-acceptance window for the same task.

Managers can scan one stream instead of opening GitHub analytics separately for a qualitative picture of assisted work.

Troubleshooting

No events after setup: Re-run the OAuth flow, confirm the integration is enabled for the intended workspace, and verify the editor is online and signed in to Copilot.

Duplicate or noisy entries: Tighten reporting scope, increase batching intervals, or disable low-value signals (raw completion counts) while keeping “accepted suggestion” summaries.

Wrong user or team: Check GitHub seat assignment versus Dailybot user mapping; some orgs need a one-time directory sync or manual alias.

Corporate proxy blocks traffic: Whitelist Dailybot hostnames and, if you use a relay, the relay’s egress URLs.

Once Copilot and Dailybot are aligned, your team gets a clearer picture of how assisted coding shows up next to human standups—without extra copy-paste in chat.

FAQ

What do I need before connecting GitHub Copilot to Dailybot?
A Dailybot workspace with permission to manage integrations, an active GitHub Copilot subscription or org policy that allows Copilot in your editor, and an IDE where Copilot runs (for example VS Code or a supported JetBrains IDE) on a machine that can reach Dailybot over HTTPS.
Where do Copilot reports show up in Dailybot?
They appear in the unified activity timeline next to human check-ins and other agent sources, labeled by source and workspace metadata so managers can scan human and agent work in one place.
Copilot events are missing—what should I check first?
Confirm the integration is enabled for the correct workspace, the IDE extension or bridge is signed in to the same GitHub account, API keys or CLI auth are valid, and your reporting scope is not set so narrow that routine sessions are filtered out.