gh-awの更新を即追従しない：72時間の待機と固定版をPythonで検査する
AIエージェントをCIに入れると、アプリの依存関係だけでなく、エージェント本体の更新も運用対象になります。「最新版へ自動更新」と「安全に更新」は同じではありません。更新直後の不具合を避けたい一方、修正版まで一律に待たせると危険が残ることもあります。
GitHub Agentic Workflowsの11月2日付週次更新では、新しく公開されたエンジンの導入を3日待たせる、設定可能なクールダウンが注目PRとして紹介されました。本稿はこの話題を入り口に、公開からの経過時間、固定した版、承認済みハッシュを別々に確認する運用を考えます。
重要なのは日付の区別です。同じ記事が取り上げるv1.0.1のリリース日は10月27日です。11月2日の新リリースではありません。また、週次更新の注目PRに載っているだけで、クールダウンがv1.0.1に同梱されているとは断定しません。設定キーや対応エンジンの網羅性は今回確認できていないため、未確認のYAMLを動く設定として載せない方針です。
以下のコードは、gh-awの内部実装を再現するものではなく、チームで採用条件を合意するための独立したPythonサンプルです。外部API、パッケージ取得、エージェント起動は行いません。
1. 何を待つのか：実行間隔と更新待機は別物
gh-awには既存のon.cooldownもあります。これは前の対象実行が終了してから次のエージェント実行まで間隔を空ける仕組みです。公式トリガー資料では、agentジョブが開始された実行を対象とし、成功・失敗にかかわらず終了から計測します。実行履歴を取得できない場合は実行を許可する、と説明されています。
一方、今回の話題は新しいエンジン版の公開から導入まで待つことです。前者は頻度、後者は依存物の採用時期を扱います。名前が似ていても、on.cooldown: 72hを設定すれば公開直後のパッケージを止められる、とは言えません。
実行間隔を4時間にしても、4時間後に最新パッケージを取れば公開直後の版を採用し得ます。逆に3日経過したエンジンでも、毎分呼べば費用は増えます。
2. 固定すべきものは一つではない
公式の版管理資料は、ローカルやCIで使うgh-aw CLIと、Actionsで動く生成済み.lock.ymlを区別しています。CLIだけ更新しても既存の生成物が同じになるとは限りません。さらに、エンジンCLIの版は別です。用語集のengine.versionはその固定に使う項目で、省略時の既定はlatestと説明されています。
次の組を一つの変更申請として保存する運用を提案します。
生成に使ったgh-awの版と、ソースMarkdownのコミット
レビューした.lock.ymlのコミットとActions参照先
採用するエンジンの厳密な版、配布元、対象OS・CPU
その配布物の公開時刻、承認済みダイジェスト、確認担当
「1.2.3」という版文字列だけでは配布物を特定できません。同じ版でもOSやCPUでファイルは異なります。今回のサンプルは配布物を一つ選んだ後の判定なので、プラットフォーム選択や取得元の真正性確認は呼び出し側の責任です。
3. 最小コード：経過時間だけで自動許可しない
Python 3.12.14、標準ライブラリのみで検証しました。外部依存はありません。policy.pyに次の関数を保存します。架空の版とハッシュを使うテストであり、実在エンジンの安全性評価ではありません。
"""Local release-adoption policy; NOT gh-aw's implementation."""
from datetime import datetime, timedelta
import re
def decide(*, version, published_at, now, sha256, approved_sha256,
revoked=False, cooldown_hours=72):
if type(cooldown_hours) is not int or cooldown_hours < 0:
raise ValueError('cooldown_hours must be a nonnegative integer')
if now.tzinfo is None or now.utcoffset() is None:
raise ValueError('now must include timezone')
if revoked:
return 'BLOCK_REVOKED'
if not isinstance(version, str) or not re.fullmatch(r'v?\d+.\d+.\d+', version):
return 'HOLD_VERSION'
if not all(isinstance(s, str) and re.fullmatch(r'[0-9a-f]{64}', s)
for s in (sha256, approved_sha256)):
return 'HOLD_DIGEST'
if sha256 != approved_sha256:
return 'BLOCK_DIGEST_MISMATCH'
try:
released = datetime.fromisoformat(published_at)
if released.tzinfo is None or released.utcoffset() is None:
return 'HOLD_TIME'
except (TypeError, ValueError):
return 'HOLD_TIME'
if released > now:
return 'HOLD_TIME'
if now - released < timedelta(hours=cooldown_hours):
return 'WAIT_COOLDOWN'
return 'ELIGIBLE_FOR_REVIEW'
ELIGIBLE_FOR_REVIEWはインストール許可ではなく、次のレビュー工程へ進めるという意味です。取り消し情報を最優先にし、latestやプレリリース、ハッシュ不明、時刻不明は保留します。プレリリースを拒むのはこのサンプルの意図的な制約であり、gh-aw全体の制約ではありません。
また、ハッシュが一致したから安全とも言えません。悪意のあるファイルを承認してしまえば一致します。比較元のapproved_sha256を候補ファイルから自動でコピーしてはいけません。信頼できる配布元と承認記録から別経路で確定させる必要があります。この関数は署名検証器でも、マルウェア検出器でもありません。
4. 実行と境界テスト
添付サンプルを展開し、sampleディレクトリで実行します。
python --version
python -m unittest -v
テストはネットワークを呼びません。実際に18件を実行し、すべて成功しました。公開から72時間ちょうどなら次のレビューへ進み、1秒前なら待機します。同じ瞬間をUTCとJSTで表した場合も結果は同じです。未来の公開時刻、時差のない日時、不正なハッシュ、失効済み配布物も確認対象に含めました。
最小の境界テストは次の形です。実行時刻を現在時刻に任せず固定するのがポイントです。
from datetime import datetime
from policy import decide
args = dict(
version="1.2.3",
published_at="2026-10-31T00:00:00+00:00",
now=datetime.fromisoformat("2026-11-03T00:00:00+00:00"),
sha256="a" * 64,
approved_sha256="a" * 64,
)
assert decide(args) == "ELIGIBLE_FOR_REVIEW"
args["now"] = datetime.fromisoformat("2026-11-02T23:59:59+00:00")
assert decide(args) == "WAIT_COOLDOWN"
日時は表示用の日付ではなく、タイムゾーン付きの公開時刻を使います。ページに「10月31日」としか書かれていないなら、午前0時と推定して72時間を計算しません。本例では不明として保留し、レジストリ等の正式な公開時刻を確認する工程に戻します。
テストで確認したのは自作判定ロジックだけです。gh-awのコンパイル、Actions実行、特定エンジンへの設定反映、モデルの応答品質や速度は未検証です。18件成功をサービス接続成功と読み替えないでください。
5. 既存CIへ入れるなら、更新PRを境界にする
まず既存の版を記録し、候補との差分をレビュー用ブランチで確認します。待機判定は更新PRの説明やチェック結果として表示し、その場で本番の依存物を書き換えない形が扱いやすいでしょう。判定結果とともに、使用した公開時刻、確認日時、ハッシュの根拠も残します。
公式資料では生成済みロックファイルを手編集しないよう案内されています。変更対象はソースと管理される依存情報にし、再生成した差分をレビューします。最新のCLIにしただけで、既存ワークフローの実行内容も安全に更新済みと扱わないことが重要です。
採用後は、読み取り専用・小さい対象から動作確認し、エラー率、必要権限、出力先、費用を以前の版と比較します。ここでは測定していないため、削減率や改善幅は示しません。ロールバック先も、単に古い版ではなく、その時点で失効していない承認済み版である必要があります。
6. 費用・認証・データを待機期間で解決しない
gh-aw自体は無償のオープンソースですが、公式FAQはエンジンに応じて推論の課金先が異なると説明しています。Actionsの計算資源や外部サービスの料金も、今回のローカルテストとは別です。固定したエンジン版が同じでも、使うモデルや入力長、実行回数が変われば支出は変わり得ます。
本サンプルにはトークン、GitHub認証、APIキーを渡しません。本番組み込み時は、推論の支払主体とリポジトリ操作権限を別々に確認します。単に判定を通すために権限を広げたり、請求先の分からない既存キーを流用したりする設計は避けます。
データ面も独立した確認事項です。コードやIssueをどのモデルへ送るか、ログに何が残るか、保存期間と削除方法、秘密情報の除外を決めます。72時間待っても、機密を送ってよいという根拠にはなりません。判定ログには承認識別子など必要最小限を残し、認証値を記録しない運用を推奨します。
7. 不向きな場面と採用判断
緊急の脆弱性修正に一律72時間を適用する運用は不向きです。待つことのリスクと、直ちに更新するリスクを担当者が比較する例外手順が必要になります。ただし例外を「すべて許可」のスイッチにせず、対象版・理由・期限・承認者を限定します。このサンプルに例外承認機能は実装していません。
公開時刻を信頼できない配布元、内容が差し替わる参照先、時計がずれたCIでも追加対策が必要です。時刻や失効情報を取得できなければ保留する方針は安全側ですが、可用性は下がります。更新待ちの責任者と対応期限まで決めないと、永久に古い版を使い続ける結果にもなります。
採用を勧めたいのは、更新頻度が高く、複数のCIが同じエンジンを利用し、レビュー済み版を説明する必要があるチームです。逆に、一度だけのローカル実験なら台帳運用の方が重い場合があります。目的は72時間という数字を守ることではなく、何を根拠に、どの配布物を、誰が本番へ進めたかを追えるようにすることです。
参照資料
確認日：2026年11月3日（Asia/Tokyo）。公式URLに限定した検索で読めた本文を照合しました。週次更新ページの直接取得は失敗しており、未確認の設定詳細は断定していません。
GitHub Agentic Workflows：11月2日週次更新
公式リリース一覧
Triggers：on.cooldown
Releases and Versioning
Glossary：Engine Version
GitHub Agentic Workflows FAQ
仓库里的活，Actions 写死又不够聪明？
GitHub 的 gh-aw：Markdown 加 YAML 前置写 agent 工作流，编译成标准 Actions。
适合把仓库自动化交给 agent 的团队，确定性活留给传统 Actions。
让它干什么，审 PR 还是查 CI 失败？
#GitHub #Agent @grok
github/gh-aw
1 like · 74 views
A feature ships, but the setup guide still describes the old version.
GitHub's daily-doc-updater checks recent changes and proposes docs updates, or does nothing if they're already covered.
The example enables auto-merge; add your own review gate.
github.com/github/gh-aw/blob/main/.github/workflo…
5 views
GitHub Agentic Workflows announcement: github.blog
Ready-made workflows: github/gh-aw
3 likes · 77 views
Markdown-powered AI agents, compiled into GitHub Actions.
GitHub’s Agentic Workflows are now GA.
I love this architecture: let agents handle reasoning, while deterministic workflows control execution and permissions.
github/gh-aw
12 views
GitHub Agentic WorkflowsがGA：stagedを無料・完全無操作と誤解しない
GitHub Agentic Workflowsを試すとき、最初に分けたいのは「AIに考えさせる」「変更を提案させる」「変更を適用する」の三段階です。staged: trueは、このうちsafe outputsによる書込みをプレビューする機能であり、AIの推論やすべての処理を止めるスイッチではありません。
GitHubは2026年10月28日、Agentic Workflowsの一般提供を発表しました。本稿では、その発表をきっかけに、導入前に検査できることと、実行しないと分からないことを整理します。実API、GitHub Actions、モデル推論は実行せず、付属コードはローカルの模擬検証だけを行っています。
何が変わったのか
Agentic Workflowsは、YAML frontmatter付きMarkdownから通常のActions YAMLを生成し、GitHub Actions上でコーディングエージェントを動かす仕組みです。用途にはIssueの分類、CI失敗の分析、ドキュメント更新などがあります。従来の手続き型CIを置き換えるより、判断が必要な一部の仕事を別ジョブとして取り出す、と考えると設計しやすくなります。
今回のGAはgithub.comのFree、Team、Enterpriseが対象です。ただし標準のCopilot CLIエンジンにはCopilotライセンスが必要です。「Freeプランで機能が使える」と「推論を含めて無償」は別です。発表は10月28日で、地域別・日本語別の提供開始日を示す告知ではありません。自社アカウントでの有効化や契約条件は別途確認が必要です。公式発表
Markdownから外部変更までの境界
流れは、設定と指示を記述し、コンパイルした実行定義を確認し、エージェントが出した候補を検査し、許可された出力を適用する順です。エージェントの読み取りと、IssueやPRを作る書込みは別の権限境界として設計されています。
重要なのは、自然言語で「変更しないで」と書くだけで境界が成立するわけではないことです。生成された実行定義、認証情報、カスタムステップも確認します。公式のSecurity Architectureも、独自の実行ステップやホスト側の権限は、エージェントのサンドボックスと同じ保護を自動では受けないと説明しています。読み取り専用のGITHUB_TOKENがあっても、別の認証情報まで消えるわけではありません。セキュリティ設計
初期検証では到達した段階も記録します。たとえば、コンパイル成功、エージェント完了、出力検査完了、外部反映成功は、それぞれ異なる事実です。提案が生成できたことを、PR作成や安全性の確認済みと扱わない台帳が必要です。
stagedで止まるもの、止まらないもの
公式の設定例ではsafe outputs全体に次のように指定できます。これは関連部分の抜粋で、単独で実行できるワークフロー全体ではありません。
safe-outputs:
staged: true
create-issue:
title-prefix: "[ai] "
labels: [automation]
組込みsafe outputsのstagedでは、対象の書込みを行う代わりにActionsのstep summaryへプレビューが出ます。一方、対象のラベルなどを検査するための読み取りは起こり得ます。また、特定の出力種類だけをstagedにし、別の種類は通常実行する設定もあります。したがってレビューでは「どこかにstagedという文字がある」ではなく、対象となる出力全体に適用されているかを見ます。Safe Outputs
独自のsafe output jobは自動でスキップされません。コード側でstagedの信号を尊重する必要があります。Staged Mode
運用提案として、最初は出力を一つ、手動起動、非機密の検証用リポジトリに限定します。スケジュール実行と複数リポジトリ連携を同時に導入すると、品質問題と権限問題の切り分けが難しくなります。プレビューに個人情報が含まれるなら、外部Issueを作らなくてもログの閲覧権限や保持期間が検討対象になります。
ローカルで導入条件を落とす最小コード
以下はgh-awの内部APIや設定スキーマの再実装ではありません。チームがレビューした事実をJSONで受け取り、未確認項目が残る計画を保留する独立したチェックリストです。項目をtrueにするのは、担当者が根拠を確認した後だけにします。
実行環境はPython 3.12.14、追加パッケージなし。ネットワークアクセス、認証情報の読取り、ファイルの変更、ワークフロー起動は行いません。
"""Offline, project-local release checklist; not a gh-aw API/schema validator."""
import json
from pathlib import Path
REQUIRED = (
"compiled_reviewed", "engine_terms_reviewed", "logs_reviewed",
"budget_approved", "identity_verified", "repository_policy_reviewed",
)
def assess(plan):
if not isinstance(plan, dict):
return {"status": "hold", "reasons": ["invalid_plan"]}
reasons = [key for key in REQUIRED if plan.get(key) is not True]
if plan.get("trigger") != "manual":
reasons.append("manual_trigger_required")
if plan.get("safe_outputs_staged") is not True:
reasons.append("staged_required")
if plan.get("custom_executable_steps") is not False:
reasons.append("custom_steps_not_reviewed")
if plan.get("detection_mode") != "strict":
reasons.append("strict_detection_required")
limit = plan.get("max_runs")
if type(limit) is not int or not 1 <= limit <= 3:
reasons.append("bounded_run_count_required")
return {"status": "hold" if reasons else "pilot_candidate",
"reasons": reasons,
"external_effects": False}
if name == "main":
import sys
plan = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8"))
result = assess(plan)
print(json.dumps(result, ensure_ascii=False, indent=2))
raise SystemExit(0 if result["status"] == "pilot_candidate" else 2)
付属のplan.jsonはレビュー項目をfalseにしてあります。未確認の計画を通すためのサンプルではありません。ZIPを展開したディレクトリで次を実行します。
python3 --version
python3 -m unittest -v
python3 release_gate.py plan.json
最初の判定はholdで、終了コードは2です。全項目の根拠を確認し条件を満たした場合だけpilot_candidateとなります。これは小規模な検証の候補という意味で、本番実行や書込みの許可ではありません。external_effects: falseも、このPythonプログラムが外部操作をしないという意味です。
テストでは、未確認項目、文字列の"true"、定期起動、staged無効、未確認の独自ステップ、warn設定、不正な実行回数、入力型、入力が変更されないことを検証しました。10件すべて成功しています。ただし、JSONの自己申告が正しいこと、gh-awのコンパイルが成功すること、実サービスが設定どおり動くことは、このテストでは証明できません。
本物のCLI検証は別工程にする
参照時点の公式リリース一覧にはv1.0.1がありますが、この記事ではgh-awをインストールも実行もしていません。Pythonの依存版と、採用候補のCLI版を混同しないようにします。採用時は使ったCLI版、入力Markdown、生成された.lock.yml、確認者を同じ変更単位で残します。リリース一覧
既存の許可済み環境で実施する次工程のコマンド候補は、次の二つです。ここでは実行していません。
gh aw validate my-workflow
gh aw compile my-workflow
validateはリンターを含む検証で、lockファイルを生成しません。compileは生成物を作る工程です。どちらも「推論結果が業務上正しい」「外部変更が承認された」の代わりにはなりません。リンター等の取得・実行を含む環境要件も確認し、単に無料のオフラインテストだとは扱わないでください。CLIリファレンス
検出、認証、費用を独立に確認する
脅威検出ジョブがあることだけで、危険な出力が必ず止まると考えないことも大切です。公式資料ではwarnとstrictを区別しており、warnでは検出結果を注記したレビュー可能な出力が公開される場合があります。本稿のチェックリストでstrictを条件にしたのは、初回検証の運用方針であって、製品が常にstrictで動くという説明ではありません。Threat Detection
認証は選んだAIエンジンで異なります。QuickstartはCopilotの組織課金やトークン等の経路を説明していますが、既存のライセンスだけで、どの組織・どのリポジトリでも実行できるとは限りません。本記事の検証ではキー作成、OAuth追加、権限変更を行っていません。導入時には、コードやIssue本文をどの提供者へ送るか、ログとartifactを誰が読めるか、利用契約と組織ポリシーを先に照合します。Quickstart
費用はActionsの実行時間とAIプロバイダーの推論費用を分けて見ます。stagedでIssue作成を止めても、推論とランナーの使用をなくすわけではありません。AICは見積り用の指標で、請求額との完全一致は保証されません。実験の回数上限、停止担当、予算確認を決め、実際の請求側でも確認します。単価や削減率は実測していません。Cost Management
採用する場合と見送る場合
候補にしやすいのは、入力範囲を限定でき、提案の良し悪しを人が確認でき、失敗しても既存CIや業務が止まらない処理です。仮例なら、公開リポジトリのIssueを一件だけ分類し、プレビューを担当者が確認するところから始められます。これは導入成果の報告ではなく、検証計画の例です。
反対に、機密コードの送信先を決められない、必ず無課金でなければならない、承認者がいない、すべての処理を決定論的に再現したい場合は、そのまま採用するのに向きません。既存の静的解析や通常のActionsで解ける問題は、まずそちらを使う判断が合理的です。
成功条件は「GAだから動かせた」ではなく、入力範囲、権限、出力、費用、停止手順を説明でき、期待外れの提案を外部変更へ進めずに済むことです。stagedを入口にしつつ、プレビュー成功と本番採用を別の判断にする。
GitHub Puts AI Agents in Your CI – Without Write Access
Three trending GitHub repos: GitHub Agentic Workflows (gh-aw), which runs AI agents in GitHub Actions from plain-English Markdown with read-only access by default; Cap, an open-source Loom alternative you can self-host; and Ardia, a free Chromium browser for the Mac with an Arc-style sidebar.
In plain language: what each repo does, how it works, who should try it, how to get started, and what to watch out for.
⏱ Chapters
0:00 Intro
0:44 gh-aw: AI agents in GitHub Actions, read-only
3:43 Cap: self-hostable Loom alternative
6:23 Ardia: open Arc-style browser for Mac
9:02 This week in dev tools
9:44 Summary
📦 Repos
1. github/gh-aw – GitHub (Go · MIT)
github/gh-aw
Install: gh extension install github/gh-aw
Quick start: github.github.com
Security architecture: github.github.com
Public preview announcement: github.blog
2. CapSoftware/Cap – Cap (Rust · AGPLv3, capture crates MIT)
CapSoftware/Cap
Download: cap.so
Self-hosting guide: cap.so
v0.6.1 release notes: github.com/CapSoftware/Cap/releases/latest
3. mantrakp04/ardia – Mantra (TypeScript · GPL-3.0 builds)
mantrakp04/ardia
Download: github.com/mantrakp04/ardia/releases/latest (macOS 14+, Apple silicon) · Homebrew: brew install mantrakp04/tap/ardia
Website: ardia.dev
📰 This week in dev tools
• Node.js security releases fix 10 vulnerabilities, including a Brotli decoder flaw (Oct 21): nodejs.org
Star counts are as of 26 October 2026. Cap's CPU figures come from its own release notes. gh-aw's agent job is read-only by default; workflow authors can change that. Summaries are simplified; see the repos for full details.
Images:
• Repo page screenshots: github.com/github/gh-aw, github.com/CapSoftware/Cap, github.com/mantrakp04/ardia · screenshot
If you found this useful, like and subscribe for the next round of trending repos.
#GitHub #OpenSource #AIAgents #DeveloperTools #GitHubActions
14 views
CVE-2026-92261: Secure Privileged GitHub Workflows Now
Cybersecurity briefing — 2026-10-24
CVE-2026-92261 affects the unified-github-workflows release check. GitHub Security Lab reports that external pull-request-controlled version data can lead to command execution in a privileged pull_request_target workflow. The reported patched release is version 1.0.44. No CVSS score is published in the official advisory.
This briefing also covers two critical gh-aw MCP advisories: GHSA-f7r8-5pqp-q5p4 (GHSL-2026-180) and GHSA-62c8-mmw9-rq5w (GHSL-2026-188/189). The advisories affect gh-aw versions earlier than 0.91.12 and describe argument-boundary issues in MCP tool handlers; the second also includes a path traversal issue. GitHub lists v0.91.12 as the patched release. The published CVSS-B assessment for the argument injection findings is 9.2 Critical; this assumes a low-trust client can reach the local/connected MCP interface and operator credentials are available.
Defensive actions:
- Update unified-github-workflows to 1.0.44 or later and gh-aw to 0.91.12 or later.
- Inventory pull_request_target jobs, reusable workflows, and their permissions.
- Do not run pull-request-controlled code or data in jobs holding unnecessary write tokens or secrets.
- Strictly validate untrusted inputs; enforce safe argument and path boundaries in tool integrations.
- Limit MCP server clients and GitHub credential scope; require approval for consequential writes.
00:00 Immediate action
00:22 CVE-2026-92261: affected workflow and impact
01:04 Why privileged pull-request contexts need care
01:37 Patch and audit checklist
02:13 gh-aw MCP critical advisories
02:53 Containment and monitoring
03:23 Bottom line
Official sources:
- GitHub Security Lab — CVE-2026-92261 / GHSL-2026-229 (published October 22, 2026): securitylab.github.com
- GitHub advisory — GHSA-f7r8-5pqp-q5p4 / GHSL-2026-180: github.com/github/gh-aw/security/advisories/GHSA-…
- GitHub advisory — GHSA-62c8-mmw9-rq5w / GHSL-2026-188 and GHSL-2026-189: github.com/github/gh-aw/security/advisories/GHSA-…
- GitHub Security Lab — AI agent-discovered advisories index: securitylab.github.com
Defensive awareness only. No exploit code, payloads, commands, or attack chains.
#CVE202692261 #GitHubActions #GitHubSecurity #MCP #AISecurity #DevSecOps #CI_CD #Cybersecurity
2 views
CVE-2026-92261: review privileged GitHub workflows now #Shorts
CVE-2026-92261: GitHub Security Lab says the unified-github-workflows release check can turn pull-request-controlled version data into command execution when a privileged pull_request_target workflow processes it. Update to v1.0.44 or later and review all privileged workflows. gh-aw MCP users should update to v0.91.12 or later for two critical argument-boundary advisories.
Sources:
- securitylab.github.com
- github.com/github/gh-aw/security/advisories/GHSA-…
- github.com/github/gh-aw/security/advisories/GHSA-…
#Shorts #CVE202692261 #GitHubActions #MCP #Cybersecurity #DevSecOps
1 like · 33 views
10 GitHub Repos That Make OpenAI Codex INSANELY Powerful
Turn OpenAI Codex CLI from a simple terminal assistant into a fully autonomous AI development agent! 🚀 We tested and ranked the top 10 open-source GitHub repositories that add MCP server connectivity, AI vision testing, container isolation, and thousands of ready-made agent skills to Codex.
👉 Which repo are you adding to your setup first? Tell us in the comments!
⏱️ CHAPTERS
0:00 Hook
0:45 Ecosystem Overview
1:41 #10 GitHub Agentic Workflows
3:18 #9 Awesome Codex Skills
4:51 #8 Awesome Agent Skills
6:28 #7 Codex CLI Container Sandbox
8:09 #6 Iris Vision UI Testing
9:44 #5 AAS Core Skill Control Plane
11:12 #4 Fullstack MCP Hub
12:21 #3 Awesome Codex CLI Directory
13:21 #2 GitHub MCP Server
14:26 #1 Official OpenAI Codex CLI
15:31 Final Verdict & Summary
🔗 REPOSITORIES IN THIS VIDEO
#10 GitHub Agentic Workflows — github/gh-aw
#9 Awesome Codex Skills — composio-community/awesome-codex-skills
#8 Awesome Agent Skills — VoltAgent/awesome-agent-skills
#7 Codex CLI container sandbox — stefanbosak/codex-cli
#6 Iris (UI vision testing) — frankbria/iris
#5 AAS Core — sickn33/agentic-awesome-skills
#4 Fullstack MCP Hub — jbulger82/Fullstack_MCP_hub
#3 Awesome Codex CLI — RoggeOhta/awesome-codex-cli
#2 GitHub MCP Server — github/github-mcp-server
#1 OpenAI Codex CLI — openai/codex
⚠️ Always review a repository's code, permissions and licence before installing it. Some projects in this list are young or small; test them in a sandbox first. This channel is not affiliated with OpenAI, GitHub or any of the listed projects.
🔔 Subscribe to Daily Useful Steps for practical AI and developer tools — small steps, everyday wins.
#OpenAICodex #AICoding #GitHub
7 likes · 1 comment · 2,206 views
Mentions
gh-awの更新を即追従しない：72時間の待機と固定版をPythonで検査する AIエージェントをCIに入れると、アプリの依存関係だけでなく、エージェント本体の更新も運用対象になります。「最新版へ自動更新」と「安全に更新」は同じではありません。更新直後の不具合を避けたい一方、修正版まで一律に待たせると危険が残ることもあります。 GitHub Agentic Workflowsの11月2日付週次更新では、新しく公開されたエンジンの導入を3日待たせる、設定可能なクールダウンが注目PRとして紹介されました。本稿はこの話題を入り口に、公開からの経過時間、固定した版、承認済みハッシュを別々に確認する運用を考えます。 重要なのは日付の区別です。同じ記事が取り上げるv1.0.1のリリース日は10月27日です。11月2日の新リリースではありません。また、週次更新の注目PRに載っているだけで、クールダウンがv1.0.1に同梱されているとは断定しません。設定キーや対応エンジンの網羅性は今回確認できていないため、未確認のYAMLを動く設定として載せない方針です。 以下のコードは、gh-awの内部実装を再現するものではなく、チームで採用条件を合意するための独立したPythonサンプルです。外部API、パッケージ取得、エージェント起動は行いません。 1. 何を待つのか：実行間隔と更新待機は別物 gh-awには既存のon.cooldownもあります。これは前の対象実行が終了してから次のエージェント実行まで間隔を空ける仕組みです。公式トリガー資料では、agentジョブが開始された実行を対象とし、成功・失敗にかかわらず終了から計測します。実行履歴を取得できない場合は実行を許可する、と説明されています。 一方、今回の話題は新しいエンジン版の公開から導入まで待つことです。前者は頻度、後者は依存物の採用時期を扱います。名前が似ていても、on.cooldown: 72hを設定すれば公開直後のパッケージを止められる、とは言えません。 実行間隔を4時間にしても、4時間後に最新パッケージを取れば公開直後の版を採用し得ます。逆に3日経過したエンジンでも、毎分呼べば費用は増えます。 2. 固定すべきものは一つではない 公式の版管理資料は、ローカルやCIで使うgh-aw CLIと、Actionsで動く生成済み.lock.ymlを区別しています。CLIだけ更新しても既存の生成物が同じになるとは限りません。さらに、エンジンCLIの版は別です。用語集のengine.versionはその固定に使う項目で、省略時の既定はlatestと説明されています。 次の組を一つの変更申請として保存する運用を提案します。 生成に使ったgh-awの版と、ソースMarkdownのコミット レビューした.lock.ymlのコミットとActions参照先 採用するエンジンの厳密な版、配布元、対象OS・CPU その配布物の公開時刻、承認済みダイジェスト、確認担当 「1.2.3」という版文字列だけでは配布物を特定できません。同じ版でもOSやCPUでファイルは異なります。今回のサンプルは配布物を一つ選んだ後の判定なので、プラットフォーム選択や取得元の真正性確認は呼び出し側の責任です。 3. 最小コード：経過時間だけで自動許可しない Python 3.12.14、標準ライブラリのみで検証しました。外部依存はありません。policy.pyに次の関数を保存します。架空の版とハッシュを使うテストであり、実在エンジンの安全性評価ではありません。 """Local release-adoption policy; NOT gh-aw's implementation.""" from datetime import datetime, timedelta import re def decide(*, version, published_at, now, sha256, approved_sha256, revoked=False, cooldown_hours=72): if type(cooldown_hours) is not int or cooldown_hours < 0: raise ValueError('cooldown_hours must be a nonnegative integer') if now.tzinfo is None or now.utcoffset() is None: raise ValueError('now must include timezone') if revoked: return 'BLOCK_REVOKED' if not isinstance(version, str) or not re.fullmatch(r'v?\d+.\d+.\d+', version): return 'HOLD_VERSION' if not all(isinstance(s, str) and re.fullmatch(r'[0-9a-f]{64}', s) for s in (sha256, approved_sha256)): return 'HOLD_DIGEST' if sha256 != approved_sha256: return 'BLOCK_DIGEST_MISMATCH' try: released = datetime.fromisoformat(published_at) if released.tzinfo is None or released.utcoffset() is None: return 'HOLD_TIME' except (TypeError, ValueError): return 'HOLD_TIME' if released > now: return 'HOLD_TIME' if now - released < timedelta(hours=cooldown_hours): return 'WAIT_COOLDOWN' return 'ELIGIBLE_FOR_REVIEW' ELIGIBLE_FOR_REVIEWはインストール許可ではなく、次のレビュー工程へ進めるという意味です。取り消し情報を最優先にし、latestやプレリリース、ハッシュ不明、時刻不明は保留します。プレリリースを拒むのはこのサンプルの意図的な制約であり、gh-aw全体の制約ではありません。 また、ハッシュが一致したから安全とも言えません。悪意のあるファイルを承認してしまえば一致します。比較元のapproved_sha256を候補ファイルから自動でコピーしてはいけません。信頼できる配布元と承認記録から別経路で確定させる必要があります。この関数は署名検証器でも、マルウェア検出器でもありません。 4. 実行と境界テスト 添付サンプルを展開し、sampleディレクトリで実行します。 python --version python -m unittest -v テストはネットワークを呼びません。実際に18件を実行し、すべて成功しました。公開から72時間ちょうどなら次のレビューへ進み、1秒前なら待機します。同じ瞬間をUTCとJSTで表した場合も結果は同じです。未来の公開時刻、時差のない日時、不正なハッシュ、失効済み配布物も確認対象に含めました。 最小の境界テストは次の形です。実行時刻を現在時刻に任せず固定するのがポイントです。 from datetime import datetime from policy import decide args = dict( version="1.2.3", published_at="2026-10-31T00:00:00+00:00", now=datetime.fromisoformat("2026-11-03T00:00:00+00:00"), sha256="a" * 64, approved_sha256="a" * 64, ) assert decide(args) == "ELIGIBLE_FOR_REVIEW" args["now"] = datetime.fromisoformat("2026-11-02T23:59:59+00:00") assert decide(args) == "WAIT_COOLDOWN" 日時は表示用の日付ではなく、タイムゾーン付きの公開時刻を使います。ページに「10月31日」としか書かれていないなら、午前0時と推定して72時間を計算しません。本例では不明として保留し、レジストリ等の正式な公開時刻を確認する工程に戻します。 テストで確認したのは自作判定ロジックだけです。gh-awのコンパイル、Actions実行、特定エンジンへの設定反映、モデルの応答品質や速度は未検証です。18件成功をサービス接続成功と読み替えないでください。 5. 既存CIへ入れるなら、更新PRを境界にする まず既存の版を記録し、候補との差分をレビュー用ブランチで確認します。待機判定は更新PRの説明やチェック結果として表示し、その場で本番の依存物を書き換えない形が扱いやすいでしょう。判定結果とともに、使用した公開時刻、確認日時、ハッシュの根拠も残します。 公式資料では生成済みロックファイルを手編集しないよう案内されています。変更対象はソースと管理される依存情報にし、再生成した差分をレビューします。最新のCLIにしただけで、既存ワークフローの実行内容も安全に更新済みと扱わないことが重要です。 採用後は、読み取り専用・小さい対象から動作確認し、エラー率、必要権限、出力先、費用を以前の版と比較します。ここでは測定していないため、削減率や改善幅は示しません。ロールバック先も、単に古い版ではなく、その時点で失効していない承認済み版である必要があります。 6. 費用・認証・データを待機期間で解決しない gh-aw自体は無償のオープンソースですが、公式FAQはエンジンに応じて推論の課金先が異なると説明しています。Actionsの計算資源や外部サービスの料金も、今回のローカルテストとは別です。固定したエンジン版が同じでも、使うモデルや入力長、実行回数が変われば支出は変わり得ます。 本サンプルにはトークン、GitHub認証、APIキーを渡しません。本番組み込み時は、推論の支払主体とリポジトリ操作権限を別々に確認します。単に判定を通すために権限を広げたり、請求先の分からない既存キーを流用したりする設計は避けます。 データ面も独立した確認事項です。コードやIssueをどのモデルへ送るか、ログに何が残るか、保存期間と削除方法、秘密情報の除外を決めます。72時間待っても、機密を送ってよいという根拠にはなりません。判定ログには承認識別子など必要最小限を残し、認証値を記録しない運用を推奨します。 7. 不向きな場面と採用判断 緊急の脆弱性修正に一律72時間を適用する運用は不向きです。待つことのリスクと、直ちに更新するリスクを担当者が比較する例外手順が必要になります。ただし例外を「すべて許可」のスイッチにせず、対象版・理由・期限・承認者を限定します。このサンプルに例外承認機能は実装していません。 公開時刻を信頼できない配布元、内容が差し替わる参照先、時計がずれたCIでも追加対策が必要です。時刻や失効情報を取得できなければ保留する方針は安全側ですが、可用性は下がります。更新待ちの責任者と対応期限まで決めないと、永久に古い版を使い続ける結果にもなります。 採用を勧めたいのは、更新頻度が高く、複数のCIが同じエンジンを利用し、レビュー済み版を説明する必要があるチームです。逆に、一度だけのローカル実験なら台帳運用の方が重い場合があります。目的は72時間という数字を守ることではなく、何を根拠に、どの配布物を、誰が本番へ進めたかを追えるようにすることです。 参照資料 確認日：2026年11月3日（Asia/Tokyo）。公式URLに限定した検索で読めた本文を照合しました。週次更新ページの直接取得は失敗しており、未確認の設定詳細は断定していません。 GitHub Agentic Workflows：11月2日週次更新 公式リリース一覧 Triggers：on.cooldown Releases and Versioning Glossary：Engine Version GitHub Agentic Workflows FAQ
仓库里的活，Actions 写死又不够聪明？ GitHub 的 gh-aw：Markdown 加 YAML 前置写 agent 工作流，编译成标准 Actions。 适合把仓库自动化交给 agent 的团队，确定性活留给传统 Actions。 让它干什么，审 PR 还是查 CI 失败？ #GitHub #Agent @grok github/gh-aw
A feature ships, but the setup guide still describes the old version. GitHub's daily-doc-updater checks recent changes and proposes docs updates, or does nothing if they're already covered. The example enables auto-merge; add your own review gate. github.com/github/gh-aw/blob/main/.github/workflo…
GitHub Agentic Workflows announcement: github.blog Ready-made workflows: github/gh-aw
Markdown-powered AI agents, compiled into GitHub Actions. GitHub’s Agentic Workflows are now GA. I love this architecture: let agents handle reasoning, while deterministic workflows control execution and permissions. github/gh-aw
GitHub Agentic WorkflowsがGA：stagedを無料・完全無操作と誤解しない GitHub Agentic Workflowsを試すとき、最初に分けたいのは「AIに考えさせる」「変更を提案させる」「変更を適用する」の三段階です。staged: trueは、このうちsafe outputsによる書込みをプレビューする機能であり、AIの推論やすべての処理を止めるスイッチではありません。 GitHubは2026年10月28日、Agentic Workflowsの一般提供を発表しました。本稿では、その発表をきっかけに、導入前に検査できることと、実行しないと分からないことを整理します。実API、GitHub Actions、モデル推論は実行せず、付属コードはローカルの模擬検証だけを行っています。 何が変わったのか Agentic Workflowsは、YAML frontmatter付きMarkdownから通常のActions YAMLを生成し、GitHub Actions上でコーディングエージェントを動かす仕組みです。用途にはIssueの分類、CI失敗の分析、ドキュメント更新などがあります。従来の手続き型CIを置き換えるより、判断が必要な一部の仕事を別ジョブとして取り出す、と考えると設計しやすくなります。 今回のGAはgithub.comのFree、Team、Enterpriseが対象です。ただし標準のCopilot CLIエンジンにはCopilotライセンスが必要です。「Freeプランで機能が使える」と「推論を含めて無償」は別です。発表は10月28日で、地域別・日本語別の提供開始日を示す告知ではありません。自社アカウントでの有効化や契約条件は別途確認が必要です。公式発表 Markdownから外部変更までの境界 流れは、設定と指示を記述し、コンパイルした実行定義を確認し、エージェントが出した候補を検査し、許可された出力を適用する順です。エージェントの読み取りと、IssueやPRを作る書込みは別の権限境界として設計されています。 重要なのは、自然言語で「変更しないで」と書くだけで境界が成立するわけではないことです。生成された実行定義、認証情報、カスタムステップも確認します。公式のSecurity Architectureも、独自の実行ステップやホスト側の権限は、エージェントのサンドボックスと同じ保護を自動では受けないと説明しています。読み取り専用のGITHUB_TOKENがあっても、別の認証情報まで消えるわけではありません。セキュリティ設計 初期検証では到達した段階も記録します。たとえば、コンパイル成功、エージェント完了、出力検査完了、外部反映成功は、それぞれ異なる事実です。提案が生成できたことを、PR作成や安全性の確認済みと扱わない台帳が必要です。 stagedで止まるもの、止まらないもの 公式の設定例ではsafe outputs全体に次のように指定できます。これは関連部分の抜粋で、単独で実行できるワークフロー全体ではありません。 safe-outputs: staged: true create-issue: title-prefix: "[ai] " labels: [automation] 組込みsafe outputsのstagedでは、対象の書込みを行う代わりにActionsのstep summaryへプレビューが出ます。一方、対象のラベルなどを検査するための読み取りは起こり得ます。また、特定の出力種類だけをstagedにし、別の種類は通常実行する設定もあります。したがってレビューでは「どこかにstagedという文字がある」ではなく、対象となる出力全体に適用されているかを見ます。Safe Outputs 独自のsafe output jobは自動でスキップされません。コード側でstagedの信号を尊重する必要があります。Staged Mode 運用提案として、最初は出力を一つ、手動起動、非機密の検証用リポジトリに限定します。スケジュール実行と複数リポジトリ連携を同時に導入すると、品質問題と権限問題の切り分けが難しくなります。プレビューに個人情報が含まれるなら、外部Issueを作らなくてもログの閲覧権限や保持期間が検討対象になります。 ローカルで導入条件を落とす最小コード 以下はgh-awの内部APIや設定スキーマの再実装ではありません。チームがレビューした事実をJSONで受け取り、未確認項目が残る計画を保留する独立したチェックリストです。項目をtrueにするのは、担当者が根拠を確認した後だけにします。 実行環境はPython 3.12.14、追加パッケージなし。ネットワークアクセス、認証情報の読取り、ファイルの変更、ワークフロー起動は行いません。 """Offline, project-local release checklist; not a gh-aw API/schema validator.""" import json from pathlib import Path REQUIRED = ( "compiled_reviewed", "engine_terms_reviewed", "logs_reviewed", "budget_approved", "identity_verified", "repository_policy_reviewed", ) def assess(plan): if not isinstance(plan, dict): return {"status": "hold", "reasons": ["invalid_plan"]} reasons = [key for key in REQUIRED if plan.get(key) is not True] if plan.get("trigger") != "manual": reasons.append("manual_trigger_required") if plan.get("safe_outputs_staged") is not True: reasons.append("staged_required") if plan.get("custom_executable_steps") is not False: reasons.append("custom_steps_not_reviewed") if plan.get("detection_mode") != "strict": reasons.append("strict_detection_required") limit = plan.get("max_runs") if type(limit) is not int or not 1 <= limit <= 3: reasons.append("bounded_run_count_required") return {"status": "hold" if reasons else "pilot_candidate", "reasons": reasons, "external_effects": False} if name == "main": import sys plan = json.loads(Path(sys.argv[1]).read_text(encoding="utf-8")) result = assess(plan) print(json.dumps(result, ensure_ascii=False, indent=2)) raise SystemExit(0 if result["status"] == "pilot_candidate" else 2) 付属のplan.jsonはレビュー項目をfalseにしてあります。未確認の計画を通すためのサンプルではありません。ZIPを展開したディレクトリで次を実行します。 python3 --version python3 -m unittest -v python3 release_gate.py plan.json 最初の判定はholdで、終了コードは2です。全項目の根拠を確認し条件を満たした場合だけpilot_candidateとなります。これは小規模な検証の候補という意味で、本番実行や書込みの許可ではありません。external_effects: falseも、このPythonプログラムが外部操作をしないという意味です。 テストでは、未確認項目、文字列の"true"、定期起動、staged無効、未確認の独自ステップ、warn設定、不正な実行回数、入力型、入力が変更されないことを検証しました。10件すべて成功しています。ただし、JSONの自己申告が正しいこと、gh-awのコンパイルが成功すること、実サービスが設定どおり動くことは、このテストでは証明できません。 本物のCLI検証は別工程にする 参照時点の公式リリース一覧にはv1.0.1がありますが、この記事ではgh-awをインストールも実行もしていません。Pythonの依存版と、採用候補のCLI版を混同しないようにします。採用時は使ったCLI版、入力Markdown、生成された.lock.yml、確認者を同じ変更単位で残します。リリース一覧 既存の許可済み環境で実施する次工程のコマンド候補は、次の二つです。ここでは実行していません。 gh aw validate my-workflow gh aw compile my-workflow validateはリンターを含む検証で、lockファイルを生成しません。compileは生成物を作る工程です。どちらも「推論結果が業務上正しい」「外部変更が承認された」の代わりにはなりません。リンター等の取得・実行を含む環境要件も確認し、単に無料のオフラインテストだとは扱わないでください。CLIリファレンス 検出、認証、費用を独立に確認する 脅威検出ジョブがあることだけで、危険な出力が必ず止まると考えないことも大切です。公式資料ではwarnとstrictを区別しており、warnでは検出結果を注記したレビュー可能な出力が公開される場合があります。本稿のチェックリストでstrictを条件にしたのは、初回検証の運用方針であって、製品が常にstrictで動くという説明ではありません。Threat Detection 認証は選んだAIエンジンで異なります。QuickstartはCopilotの組織課金やトークン等の経路を説明していますが、既存のライセンスだけで、どの組織・どのリポジトリでも実行できるとは限りません。本記事の検証ではキー作成、OAuth追加、権限変更を行っていません。導入時には、コードやIssue本文をどの提供者へ送るか、ログとartifactを誰が読めるか、利用契約と組織ポリシーを先に照合します。Quickstart 費用はActionsの実行時間とAIプロバイダーの推論費用を分けて見ます。stagedでIssue作成を止めても、推論とランナーの使用をなくすわけではありません。AICは見積り用の指標で、請求額との完全一致は保証されません。実験の回数上限、停止担当、予算確認を決め、実際の請求側でも確認します。単価や削減率は実測していません。Cost Management 採用する場合と見送る場合 候補にしやすいのは、入力範囲を限定でき、提案の良し悪しを人が確認でき、失敗しても既存CIや業務が止まらない処理です。仮例なら、公開リポジトリのIssueを一件だけ分類し、プレビューを担当者が確認するところから始められます。これは導入成果の報告ではなく、検証計画の例です。 反対に、機密コードの送信先を決められない、必ず無課金でなければならない、承認者がいない、すべての処理を決定論的に再現したい場合は、そのまま採用するのに向きません。既存の静的解析や通常のActionsで解ける問題は、まずそちらを使う判断が合理的です。 成功条件は「GAだから動かせた」ではなく、入力範囲、権限、出力、費用、停止手順を説明でき、期待外れの提案を外部変更へ進めずに済むことです。stagedを入口にしつつ、プレビュー成功と本番採用を別の判断にする。
GitHub Puts AI Agents in Your CI – Without Write Access Three trending GitHub repos: GitHub Agentic Workflows (gh-aw), which runs AI agents in GitHub Actions from plain-English Markdown with read-only access by default; Cap, an open-source Loom alternative you can self-host; and Ardia, a free Chromium browser for the Mac with an Arc-style sidebar. In plain language: what each repo does, how it works, who should try it, how to get started, and what to watch out for. ⏱ Chapters 0:00 Intro 0:44 gh-aw: AI agents in GitHub Actions, read-only 3:43 Cap: self-hostable Loom alternative 6:23 Ardia: open Arc-style browser for Mac 9:02 This week in dev tools 9:44 Summary 📦 Repos 1. github/gh-aw – GitHub (Go · MIT) github/gh-aw Install: gh extension install github/gh-aw Quick start: github.github.com Security architecture: github.github.com Public preview announcement: github.blog 2. CapSoftware/Cap – Cap (Rust · AGPLv3, capture crates MIT) CapSoftware/Cap Download: cap.so Self-hosting guide: cap.so v0.6.1 release notes: github.com/CapSoftware/Cap/releases/latest 3. mantrakp04/ardia – Mantra (TypeScript · GPL-3.0 builds) mantrakp04/ardia Download: github.com/mantrakp04/ardia/releases/latest (macOS 14+, Apple silicon) · Homebrew: brew install mantrakp04/tap/ardia Website: ardia.dev 📰 This week in dev tools • Node.js security releases fix 10 vulnerabilities, including a Brotli decoder flaw (Oct 21): nodejs.org Star counts are as of 26 October 2026. Cap's CPU figures come from its own release notes. gh-aw's agent job is read-only by default; workflow authors can change that. Summaries are simplified; see the repos for full details. Images: • Repo page screenshots: github.com/github/gh-aw, github.com/CapSoftware/Cap, github.com/mantrakp04/ardia · screenshot If you found this useful, like and subscribe for the next round of trending repos. #GitHub #OpenSource #AIAgents #DeveloperTools #GitHubActions
CVE-2026-92261: Secure Privileged GitHub Workflows Now Cybersecurity briefing — 2026-10-24 CVE-2026-92261 affects the unified-github-workflows release check. GitHub Security Lab reports that external pull-request-controlled version data can lead to command execution in a privileged pull_request_target workflow. The reported patched release is version 1.0.44. No CVSS score is published in the official advisory. This briefing also covers two critical gh-aw MCP advisories: GHSA-f7r8-5pqp-q5p4 (GHSL-2026-180) and GHSA-62c8-mmw9-rq5w (GHSL-2026-188/189). The advisories affect gh-aw versions earlier than 0.91.12 and describe argument-boundary issues in MCP tool handlers; the second also includes a path traversal issue. GitHub lists v0.91.12 as the patched release. The published CVSS-B assessment for the argument injection findings is 9.2 Critical; this assumes a low-trust client can reach the local/connected MCP interface and operator credentials are available. Defensive actions: - Update unified-github-workflows to 1.0.44 or later and gh-aw to 0.91.12 or later. - Inventory pull_request_target jobs, reusable workflows, and their permissions. - Do not run pull-request-controlled code or data in jobs holding unnecessary write tokens or secrets. - Strictly validate untrusted inputs; enforce safe argument and path boundaries in tool integrations. - Limit MCP server clients and GitHub credential scope; require approval for consequential writes. 00:00 Immediate action 00:22 CVE-2026-92261: affected workflow and impact 01:04 Why privileged pull-request contexts need care 01:37 Patch and audit checklist 02:13 gh-aw MCP critical advisories 02:53 Containment and monitoring 03:23 Bottom line Official sources: - GitHub Security Lab — CVE-2026-92261 / GHSL-2026-229 (published October 22, 2026): securitylab.github.com - GitHub advisory — GHSA-f7r8-5pqp-q5p4 / GHSL-2026-180: github.com/github/gh-aw/security/advisories/GHSA-… - GitHub advisory — GHSA-62c8-mmw9-rq5w / GHSL-2026-188 and GHSL-2026-189: github.com/github/gh-aw/security/advisories/GHSA-… - GitHub Security Lab — AI agent-discovered advisories index: securitylab.github.com Defensive awareness only. No exploit code, payloads, commands, or attack chains. #CVE202692261 #GitHubActions #GitHubSecurity #MCP #AISecurity #DevSecOps #CI_CD #Cybersecurity
CVE-2026-92261: review privileged GitHub workflows now #Shorts CVE-2026-92261: GitHub Security Lab says the unified-github-workflows release check can turn pull-request-controlled version data into command execution when a privileged pull_request_target workflow processes it. Update to v1.0.44 or later and review all privileged workflows. gh-aw MCP users should update to v0.91.12 or later for two critical argument-boundary advisories. Sources: - securitylab.github.com - github.com/github/gh-aw/security/advisories/GHSA-… - github.com/github/gh-aw/security/advisories/GHSA-… #Shorts #CVE202692261 #GitHubActions #MCP #Cybersecurity #DevSecOps
10 GitHub Repos That Make OpenAI Codex INSANELY Powerful Turn OpenAI Codex CLI from a simple terminal assistant into a fully autonomous AI development agent! 🚀 We tested and ranked the top 10 open-source GitHub repositories that add MCP server connectivity, AI vision testing, container isolation, and thousands of ready-made agent skills to Codex. 👉 Which repo are you adding to your setup first? Tell us in the comments! ⏱️ CHAPTERS 0:00 Hook 0:45 Ecosystem Overview 1:41 #10 GitHub Agentic Workflows 3:18 #9 Awesome Codex Skills 4:51 #8 Awesome Agent Skills 6:28 #7 Codex CLI Container Sandbox 8:09 #6 Iris Vision UI Testing 9:44 #5 AAS Core Skill Control Plane 11:12 #4 Fullstack MCP Hub 12:21 #3 Awesome Codex CLI Directory 13:21 #2 GitHub MCP Server 14:26 #1 Official OpenAI Codex CLI 15:31 Final Verdict & Summary 🔗 REPOSITORIES IN THIS VIDEO #10 GitHub Agentic Workflows — github/gh-aw #9 Awesome Codex Skills — composio-community/awesome-codex-skills #8 Awesome Agent Skills — VoltAgent/awesome-agent-skills #7 Codex CLI container sandbox — stefanbosak/codex-cli #6 Iris (UI vision testing) — frankbria/iris #5 AAS Core — sickn33/agentic-awesome-skills #4 Fullstack MCP Hub — jbulger82/Fullstack_MCP_hub #3 Awesome Codex CLI — RoggeOhta/awesome-codex-cli #2 GitHub MCP Server — github/github-mcp-server #1 OpenAI Codex CLI — openai/codex ⚠️ Always review a repository's code, permissions and licence before installing it. Some projects in this list are young or small; test them in a sandbox first. This channel is not affiliated with OpenAI, GitHub or any of the listed projects. 🔔 Subscribe to Daily Useful Steps for practical AI and developer tools — small steps, everyday wins. #OpenAICodex #AICoding #GitHub