ChatGPT team tasks for a weekly engineering update

By Rogier Muller09.29.26
ChatGPT team tasks for a weekly engineering update

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

ChatGPT team tasks let a team in a Business or Enterprise workspace run shared work on a schedule or when an app event happens, such as a new Slack message. OpenAI announced them at DevDay on 29 September 2026, and the Team Tasks admin guide covers setup. For an engineering team that already works in Codex, two jobs make sense first: a Monday update built from GitHub activity, and a triage summary when labelled pull requests move.

What ChatGPT team tasks are and who gets them

A team in ChatGPT is a shared place where colleagues keep pages, plugins and tasks. It is separate from workspace groups synced through SCIM and from Slack or Microsoft Teams channels. You cannot import or sync membership from either; you add people in ChatGPT.

A team task runs in the cloud with the team's service account and the app connections the team has configured. It does not inherit the creator's personal memories, custom instructions or chat history. That matters for engineers: whatever the task knows about your repository has to be in its instructions, a linked source or a skill.

Availability at launch is all Business and Enterprise plans. Team tasks use workspace credits, and team spending limits are separate from user limits.

The link to Codex is practical. The scheduled tasks docs say Codex CLI and the IDE extension do not provide the Scheduled management interface. Use them to draft and test the prompt or skill, then create the task in ChatGPT on the web or in the desktop app.

How to enable team tasks in your workspace

Two workspace permissions gate the feature. A workspace owner turns them on for the right people through workspace settings or custom roles.

  • Create teams lets someone create a team.
  • Create and manage team tasks lets someone create or edit team tasks. The FAQ on the same page calls it Create and manage team automations.

A workspace admin also sets up and authorizes the workspace connections the task will use, for example GitHub and Slack, and chooses who can find them. Then the team owner builds the team:

  1. Open Settings > Teams, select Create team, enter a name and an optional description, and select Create.
  2. Review who should see earlier runs and generated files, then invite colleagues by name or email.
  3. Add the connections the team needs, check each one's data and action permissions, and finish any required sign-in before unattended work starts.

Build the weekly engineering update

Open Scheduled > + New Task, select the Team toggle and pick the team that owns the task. Choose Schedule as the trigger and check the timing and time zone. Monday morning in the time zone of most readers is a sensible default.

In Instructions, describe the goal, the expected output, success criteria and guardrails. Here is a starting point you can adapt. It is our own wording, not a template from the docs:

Goal: a weekly engineering update for the payments team.
Sources: merged pull requests in acme/payments-api and acme/payments-web
from the last 7 days, via the GitHub connection.
Output: group changes by workstream, 2-4 sentences each, with PR links inline.
List open pull requests older than 5 days under "Waiting on review".
Success: every claim links to a PR. No commit hashes.
Guardrails: read-only on GitHub. Do not post anywhere.
If a source is unavailable, say which one and stop.

Review Plugins and Advanced settings, including Model. The model list comes from the team's access and may differ from your personal account. Select Create, then Run now, and read the result in Previous runs. Use Edit to tighten the instructions until two runs in a row need no correction.

Add an event-triggered triage task

The scheduled tasks docs list supported event triggers for Gmail, Slack and GitHub. The GitHub trigger fires on pull request activity in a repository. You can filter by pull request, author, title or label, and choose whether reviews, comments, commit updates or only merges should trigger the task. For Slack, add @ChatGPT to every channel the task watches. Reactions, edits, deletes and direct messages are not supported triggers.

One task can use several event triggers, but it cannot combine event triggers with a time schedule. So triage is a second task. A good first version watches pull requests labelled bug and writes a short summary: what changed, which tests the author says they ran, and which files the change touches.

When several matching events arrive close together, ChatGPT may combine them in one run. Confirm that the team task trigger picker in your workspace shows the same events before you depend on one.

Weekly update or triage task: which to start with

Question Weekly engineering update Pull request triage
Trigger Schedule, for example Monday 09:00 GitHub pull request events with a label filter
Connection needed GitHub, read access GitHub, plus Slack if it posts a summary
Output One report per week One short note per event batch
Who reads it Team lead before sharing it further The on-call engineer for that week
First failure mode Missing or stale sources Noise from comment and commit-update events

Start with the weekly update if nobody owns triage yet. A report with one clear reader gets reviewed. A triage note with no owner gets ignored.

Limits to check before you rely on it

  • New members can see all earlier runs and generated files. Individual tasks and runs cannot have separate access restrictions.
  • A connection's account decides what data and actions the task can reach. That can be more than a member's own access.
  • Team tasks can write to connected systems, such as posting to Slack, if the tool and connection allow it. Unattended runs cannot complete a new app sign-in and remain subject to action-approval requirements.
  • Pausing stops future runs. Neither pausing nor deleting a task should be relied on to interrupt an active run.
  • The team task docs do not describe opening pull requests. Keep code changes in Codex, where you review a diff and test results.

We teach the same split in our Delegate, Review, Own method: the task writes the report, and a named engineer decides what to do with it. Pick one update your team already writes by hand, test its instructions in Codex CLI or a chat, and schedule it after two clean Run now results.

Further reading