Issue fields are now generally available for all GitHub organizations on Free, Team, Enterprise, and GitHub Enterprise Cloud with data residency plans and will ship in GitHub Enterprise Server 3.23. Issue fields bring structured, typed metadata to issues, making it easy to track priority, effort, dates, and custom values consistently across your organization.

Since public preview in May, more than 40,000 organizations have adopted issue fields to add structured metadata that’s searchable, reportable, and consistent across every repository.

What’s new since public preview:

  • Issue fields on the issues list: Field values now appear directly on the repository issues list, so you can scan priority, effort, and other metadata at a glance without opening each issue.
  • Public project support: Issue fields now work in public projects, with visibility controls so organizations can decide which fields are visible to nonmembers. Logged-out users can also see public fields.
  • MCP integration: Issue fields are now accessible through GitHub’s MCP server, enabling AI tools like Copilot to read and set field values when creating or updating issues.
  • Internationalization: Field names now support non-English characters, matching parity with issue types.
  • Bug fixes and reliability: Fixed issues with field updates not reflecting in issue timestamps, project view sorting not updating when field option order changes, fields not appearing correctly in exclusion autocomplete, and single-select options not displaying in the right order with colors.

Every organization automatically gets four default fields (Priority, Effort, Start date, and Target date) that work out of the box. Organization admins can customize fields, add new ones, and configure which fields appear on each issue type from Settings > Planning > Issue fields.

To learn more, see the issue fields documentation. Share feedback in the community discussion.

Also in this release

Edit history for issues and pull requests is now limited to 100 entries

GitHub now enforces a limit of 100 stored edits per content item for issues, issue comments, pull requests, and pull request review comments. When a new edit pushes the count beyond 100, the oldest intermediate edits are automatically removed while preserving the original content and the most recent 99 changes.

This limit aligns stored data with actual usage, where over 97% of API consumers never paginate beyond the first page. The original content and most recent 99 edits are always preserved. The GraphQL userContentEdits connection and REST API continue to work as before. This applies to all plans and will ship in GitHub Enterprise Server 3.23.