#GitHub

0 today

Sep 25Friday

GitHub Blog · AI & MLSep 25, 04:00

When chat is the wrong UI

GitHub Copilot 应用推出 canvas，一种运行在应用内、无浏览器外壳的全栈小应用，可与 Copilot 智能体双向通信，并能在本地执行代码、调用第三方 API。作者认为聊天只是 AI 的通用兜底界面，用户明确任务时更该让智能体生成可复用工具，而非把智能体本身当工具、白白消耗 token。示例包括 Connect 4 游戏、Winget 包管理、SQLite 操作和开发工作流自动化。

Sep 24Thursday

GitHub Blog · AI & MLSep 24, 02:29

Rendering huge pull requests in the GitHub Copilot app

GitHub Copilot 应用重建了 pull request 视图，以流畅渲染含 2,200 个文件、超百万行改动和 400 多条行内评论的超大 PR。其做法是把文档高度拆成确定性的代码几何与动态评论块两套几何：代码行高提前精确算好，评论高度按块懒测量并锚定到文件、行与侧，避免滚动跳动。

Sep 11Friday

GitHub Blog · AI & MLSep 11, 05:31

GitHub Copilot app for Beginners: Using the diff, terminal, and browser

GitHub Copilot 应用内置 diff、终端和浏览器三个面板，让用户无需离开应用即可审查、运行和预览 AI 智能体生成的代码变更。diff 面板以绿色和红色高亮显示代码的增删改，终端面板支持直接运行项目命令并可通过 Run 按钮配置脚本，浏览器面板则提供 Pick & Polish 工具来选取页面元素并让智能体调整。

Sep 4Friday

GitHub Blog · AI & MLSep 4, 00:00

GitHub Copilot app for Beginners: Run several agents at once

GitHub Copilot 应用支持同时运行多个智能体会话，每个会话运行在独立的 Git worktree 上，互不干扰且各自保留上下文，可随时切换并从中断处继续。用户可在会话视图中查看各任务标题与进度，例如在同一项目上并行执行 funded sort 开发、无障碍审查和测试运行。

Sep 25, 2025Thursday

OpenAI NewsSep 25, 19:00

More ways to work with your team and tools in ChatGPT

OpenAI rolled out shared projects for ChatGPT Business on September 25, 2025, and made them available for Enterprise and Edu plans. Shared projects support email or link invites, two access levels, and private project memory; Enterprise and Edu have them off by default under admin control. OpenAI also added Gmail, Google Calendar, Outlook, Teams, SharePoint, GitHub, Dropbox, and Box connectors, and said ChatGPT can now choose connectors automatically per prompt.

Why it matters: HKR-H/K/R all pass: shared projects, 8 connectors, and prompt-routed connector selection are concrete workflow changes with clear admin controls. I keep it below 85 because this is a collaboration-layer product update, not a model release or a broad capability jump.

Take

OpenAI is filling the gap between Slack, Notion, and Copilot with shared projects for ChatGPT Business, also available to Enterprise and Edu but off by default. The concrete hooks are two permission levels, private project memory, email/link invites, and connectors for Gmail, Calendar, Outlook, Teams, SharePoint, GitHub, Dropbox, and Box.

I don’t buy the “team collaboration” framing yet. Chat/edit access is too coarse when project memory can accumulate client details, files, and instructions. Enterprise buyers will ask about audit trails, retention, revocation, and cross-project leakage. ISO 27001, 27017, 27018, 27701, plus expanded SOC 2, gets OpenAI through procurement, not into the workflow. The sharper move is automatic connector selection: once ChatGPT decides whether to query GitHub or email, it becomes an internal retrieval router, and security teams will treat that very differently from a chatbot.

Sep 15, 2025Monday

OpenAI NewsSep 15, 18:00

Introducing upgrades to Codex

OpenAI released GPT-5-Codex and made it the default model for Codex cloud tasks and code review; in testing, it worked independently for more than 7 hours on complex tasks. OpenAI says it used 93.7% fewer tokens than GPT-5 on the lowest 10% of employee turns, while spending 2x longer reasoning, editing, and testing on the highest 10%. The key point is one model now spans interactive coding and long-running agentic execution; pricing and full availability details are not fully disclosed in the provided body.

Why it matters: This is a substantive OpenAI developer-tool update: GPT-5-Codex becomes the default for Codex cloud tasks and code review, with concrete numbers on 7-hour autonomy and token use. HKR-H/K/R all pass; pricing and full availability are not fully disclosed in the excerpt, so it stays

Take

OpenAI made one very specific move here: GPT-5-Codex is now the default for Codex cloud tasks and code review, and the company says it handled complex tasks autonomously for more than 7 hours in testing. My read is blunt: this is not just “a better coding model.” It is OpenAI trying to collapse three product surfaces—interactive pair programming, async cloud execution, and PR review—onto one base model. That matters more than any single benchmark. Once the default path is unified, usage data, tool traces, repository context, and failure cases all feed the same training loop. Standalone coding-agent products then get squeezed on distribution first and data second.

The article gives two numbers that point to the intended architecture. On the lowest 10% of employee turns by token usage, GPT-5-Codex used 93.7% fewer tokens than GPT-5. On the highest 10%, it spent 2x longer reasoning, editing, and testing. That looks like dynamic compute allocation: be cheap and fast on trivial work, spend budget on hairy repository tasks. I’ve thought for a while that coding agents live or die on this exact tradeoff. Small requests cannot feel sluggish. Large refactors cannot be treated like autocomplete. Anthropic pushed in a similar direction by tying Claude Code closely to the Sonnet line, with long context and tool use as the pitch. Cursor, Cognition, and others spent the last year trying to solve the same UX problem: how do you make instant chat and long-running background execution feel like one system instead of two stitched products? OpenAI is now saying the model itself should absorb more of that coordination.

I still have some doubts about the evidence presented. The 93.7% figure only covers the lowest 10% of requests by token volume. That bucket can easily be dominated by small fixes, formatting changes, and lightweight Q&A. It is the easiest place to post a dramatic efficiency gain. The “2x longer on the highest 10%” claim shows willingness to spend more compute, not proof of better outcomes. In the provided body, I do not see the full benchmark table, code-review false positive rates, repo-level refactor success rates, or side-by-side conditions against GPT-5, Claude Code, or Google’s coding stack. The capability direction is clear. The evaluation framing is still thin.

One detail I do buy as important is the emphasis on AGENTS.md adherence, plus the Gitea refactor example touching 232 files and 3,541 lines. That tells you OpenAI knows where enterprise adoption actually gets blocked. The problem is no longer “can the model write a function.” The problem is whether it behaves inside a real repo: follows project rules, runs the right test commands, respects dangerous paths, keeps style consistent, and produces reviewable diffs. A lot of teams hit the same wall this year: the agent can modify code, but not in a way you trust enough to merge without babysitting. Repository behavior is where coding agents stop being a demo and start being a systems problem.

The company is also betting that one model can serve as both author and reviewer. That will improve speed because both roles share the same context and tool state. I do not fully buy the safety story yet. When the same model family writes the code, writes the tests, and reviews the patch, you also risk a very tidy loop of self-consistent blind spots. Plenty of teams learned this the hard way over the last year: pass rates go up, but escaped defects do not fall in the same proportion. I do not see disclosed review precision, recall, or any separation design for “model-generated code reviewed by the same model family.” Without that, “catches critical bugs before they ship” reads more like aspiration than established operating data.

The September 23 update is strategically important. GPT-5-Codex is available via API key, in the Responses API only, and priced the same as GPT-5. That pricing signal is stronger than most of the launch prose. If agentic coding lands at parity with the general flagship model, OpenAI is telling the market that coding is no longer a premium side SKU. It is becoming a default operating mode of the frontier model. That is good news for developers. It is bad news for companies whose whole business is a thin wrapper around a coding-specialized model.

What I want next is not another “7 hours” claim. I want to know how those 7 hours break down: useful edit cycles, test waiting time, tool retries, environment recovery, and points where a human had to step in. Long-running execution sounds impressive. In practice, the hard part is state management and failure recovery. The provided body does not disclose completion curves, intervention rates, or repository-size distribution. Until that shows up, I’d treat GPT-5-Codex as a serious product consolidation move, not final proof that one model can own the whole software engineering workflow.

OpenAI NewsSep 15, 08:00

Addendum to GPT-5 system card: GPT-5-Codex

OpenAI published a GPT-5-Codex system card addendum on September 15, 2025, stating the model is optimized for agentic coding in Codex and is available in terminal, IDE, web, GitHub, and the ChatGPT mobile app. The post says it uses reinforcement learning on real-world coding tasks, plus safety training for harmful tasks and prompt injection, with sandboxing and configurable network access. Benchmark scores, pricing, and context window are not disclosed.

Why it matters: HKR-H/K/R all pass: this is an OpenAI coding-agent model spanning terminal, IDE, GitHub, web, and mobile, with concrete training and safety details. I kept it below 85 because benchmarks, pricing, and context window are not disclosed in the body.

Take

OpenAI exposed GPT-5-Codex across five surfaces. This addendum is about execution boundaries, not raw upside. The post names terminal, IDE, web, GitHub, and the ChatGPT mobile app. It also names RL on real coding tasks, prompt-injection training, sandboxing, and configurable network access. Benchmarks, pricing, and context window are not disclosed.

My read is pretty simple: OpenAI is no longer selling “better code generation” as the center of the story. It is selling a claim that users can trust the model to act. Once coding becomes agentic, the risk is not a bad completion in one file. The risk is the whole execution chain: reading the repo, invoking tools, running tests, touching secrets, and reaching outside the environment. A system card addendum that spends its scarce space on harmful-task mitigation, prompt injection, sandboxing, and network controls is telling you where OpenAI thinks the market has moved. Static coding quality still matters. Operational safety now decides adoption.

This also feels defensive in a very specific way. Over the last year, code products have converged on the same narrative: longer-horizon repo work, tool use, autonomous edits, and PR-ready output. Anthropic pushed hard into agentic coding. GitHub Copilot kept its IDE distribution edge. Cursor-style products trained users to expect whole-repo edits, not autocomplete. OpenAI did not answer that pressure here with a benchmark table or a price cut. I read that as one of two things. Either GPT-5-Codex differentiates more on execution stack integration than on public evals, or OpenAI does not want this launch flattened into another benchmark knife fight. The article does not give enough evidence to choose between those two.

I’m also cautious about the phrase “reinforcement learning on real-world coding tasks.” The direction makes sense. codex-1 was already framed that way, and plenty of code models have since moved toward repo-level tasks and test-driven feedback loops. The problem is that “real-world” covers a lot of ground. What task mix? What repo sizes? Single-file fixes or cross-service changes? What is the success criterion beyond passing tests? How broad is the prompt-injection coverage? None of that is unpacked here. Without those conditions, it is hard to tell whether the safety training closes known holes or actually holds up under multi-step agent behavior.

The network piece is where I most want to push back. “Configurable network access” sounds modest on paper. In practice, that setting is a fault line. Without network access, an agent mostly reads local files, edits code, runs builds, and executes tests. With network access, the threat model expands immediately: dependency poisoning, credential leakage, untrusted documentation, malicious issue content, and remote tool compromise. By 2024 and 2025, the field had already learned a fairly hard lesson about prompt injection: model-side alignment alone does not solve toolchain-level attacks. If OpenAI wants GPT-5-Codex to be treated as a serious coding agent platform, the hard product questions are default-deny behavior, secret scoping, filesystem boundaries, auditability, and rollback. This addendum acknowledges the right categories. It does not disclose default policies, false-positive rates, or the cost those controls impose on task completion.

Distribution is the stronger signal here. Shipping the same model across five entry points says OpenAI is not treating GPT-5-Codex as just another API SKU. It is trying to own the behavior layer. Terminal targets power users. IDE captures day-to-day editing flow. GitHub captures PR review and repo collaboration. Web catches lighter-weight tasks. The mobile app is the interesting one. Few people want to write serious code on a phone. The phone use case is orchestration: check CI, approve an action, inspect a diff, kick off a fix, ask for status. That suggests OpenAI wants the coding agent to become a persistent execution identity, not just a desktop assistant. I buy that direction. I do not buy it as safe by default unless the permission model is unusually tight.

There is a bigger context the article does not spell out. Code models are drifting from “code generators” toward “software engineering agents,” and the evaluation stack should change with them. The old metrics were HumanEval-style snippets, SWE-bench-style issue resolution, or internal PR acceptance rates. Once the model can drive a terminal and touch the network, enterprise buyers care about different numbers: completion rate under policy constraints, rollback rate, rate of privilege escalation attempts, human takeover frequency, and audit completeness. None of those are disclosed here. I get that a system card is not a launch keynote. Still, without those numbers, we know the guardrails exist, but we do not know how expensive they are or how much capability they shave off.

So I land in a mixed place. I like that OpenAI is no longer pretending coding is just “write better code.” The company is acknowledging that execution safety is the main battlefield. I’m skeptical because the public material is still mostly principle-level. Anyone building AI developer tools knows principles are the easy part. Default configurations are hard. Cross-surface consistency is harder. If terminal, IDE, GitHub, web, and mobile all hit the same underlying agent behavior, “sandboxed” is not enough as a public answer.

If you run an engineering org, this update is enough to change how you scope pilots. Don’t start by asking whether GPT-5-Codex writes cleaner code than the last model. Ask whether network is off by default, how non-repo resources are isolated, how actions are replayed, and what the recovery path looks like after a bad tool call. OpenAI did not publish a performance scorecard here. It published a liability map.

May 16, 2025Friday

OpenAI NewsMay 16, 16:00

Addendum to OpenAI o3 and o4-mini system card: Codex

OpenAI published a May 16, 2025 addendum to the o3 and o4-mini system card, stating that Codex is a cloud coding agent powered by codex-1, an o3 variant tuned for software engineering. Each agent runs in an isolated cloud container preloaded with the user's code and environment, then loses internet access while it reads or edits files and runs tests, linters, and type checkers. The practical detail is the audit trail: Codex cites terminal logs and files, and its output can be exported as a GitHub PR or local diff.

Why it matters: This clears HKR-H/K/R because the addendum adds concrete execution details: isolated cloud containers, user-defined dev envs, internet disabled after setup, and test-running behavior. Strong featured score, but not p1: it is supporting safety documentation, not the primary launch

Take

OpenAI put Codex into the o3 and o4-mini system card addendum to define coding agents as a runtime-and-safety product, not just a stronger model. The important fact here is operational: one agent gets one cloud container, the repo and dev environment are preloaded, internet is disabled after setup, and the model can only read or edit files and run tests, linters, and type checks inside that box. For people shipping this into real repos, that matters more than “codex-1 is an o3 variant tuned for software engineering.”

I buy the product direction. Over the last year, the field has learned that code agents do not fail because they cannot emit plausible code. They fail because they leave weak evidence, operate in messy environments, and make changes that are hard to inspect or roll back. That is why the article’s most practical detail is the audit trail: terminal-log citations, file citations, and export into a GitHub PR or a local diff. This pushes the agent away from “chat that touched my repo” and toward “a constrained teammate operating inside CI-like guardrails.”

There is strong outside context for this. Cognition’s Devin pushed the autonomous-engineer story early, but a lot of user feedback landed on environment reliability and reviewability rather than raw generation quality. GitHub’s agent efforts also kept converging on the same shape: work inside the repo, produce diffs, fit the pull-request workflow, and make the system legible to humans. Anthropic made a similar bet in coding workflows by leaning on tool use and iterative execution. So OpenAI is not inventing the category here. It is standardizing a stance: a code agent needs sandboxing, verification hooks, and an output format that plugs into existing engineering process.

I still have some doubts. The addendum is thin on the numbers that would tell you whether this is robust or just well-packaged. There is no task pass rate, no acceptance rate for generated PRs, no data on regressions, and no safety metrics for prompt injection, malicious test suites, dependency abuse, or container escape attempts. If you are going to sell “verifiable evidence of actions,” I want to see the eval design. What attacks were tried? What percentage was blocked? Under what repo conditions did the agent fail? The body does not disclose that.

There is also a subtle failure mode in OpenAI’s own description. It says codex-1 was reinforcement-trained on real-world coding tasks to mirror human style and PR preferences, and to iteratively run tests until passing results are achieved. That is a sensible optimization target, but it can also teach a model to overfit to the verifier you gave it. Anyone who has maintained production code knows passing tests are not the same as a good change, especially in repos with weak coverage, flaky suites, broad lint settings, or brittle fixtures. The article does not say how Codex behaves when tests are incomplete, contradictory, or easy to game. It also does not say whether the evidence trail is exhaustive or selectively surfaced by the model. That gap matters.

The bigger pattern is that code is still the cleanest wedge for serious agent products. Repos, type systems, tests, and PR review already provide a verification scaffold that office workflows usually lack. I have thought for a while that coding agents would find a stable commercial form earlier than general-purpose knowledge-work agents for exactly that reason: the feedback loop is short, acceptance criteria are concrete, and failure is easier to localize. This addendum fits that pattern well.

My pushback is against the implied comfort level. Logs are evidence, not guarantees. A PR is a delivery format, not proof of quality. For high-trust deployment, teams still need answers on secrets exposure, branch protections, dependency allowlists, container reproducibility, cross-task memory, and incident handling. OpenAI has outlined the right shape of the system. It has not yet shown enough hard evaluation to treat that shape as solved.

OpenAI NewsMay 16, 16:00

Introducing Codex

OpenAI released the Codex research preview on May 16, 2025, a cloud software engineering agent powered by codex-1 that can handle multiple coding tasks in parallel. It runs each task in an isolated sandbox, can read and edit repos, execute tests and commands, and usually finishes in 1 to 30 minutes with terminal logs and test outputs as evidence. It launched for ChatGPT Pro, Business, and Enterprise users, then expanded to Plus on June 3; the post excerpt does not fully disclose pricing or complete limitations.

Why it matters: This is a same-day write: OpenAI moved from code assistance to a cloud software-engineering agent, with launch access for ChatGPT Pro, Business, and Enterprise. HKR-H/K/R all pass, with concrete mechanics and verifiable outputs; incomplete pricing and limits keep it at 88.

Take

OpenAI launched Codex inside ChatGPT with isolated cloud sandboxes and 1–30 minute task runtimes. My take is pretty simple: this is not mainly a “better coding model” story. It is OpenAI trying to productize the whole loop — read repo, edit files, run tests, produce a PR — and then capture distribution through ChatGPT before that workflow settles elsewhere.

The important part in the post is not the brand name. It is the execution model. Each task runs independently in its own environment, preloaded with the repository. Codex can read and edit files, run test harnesses, linters, and type checkers, then return terminal logs and test outputs as evidence. That evidence layer matters. Over the last year, the code-agent field kept running into the same trust problem: code generation is easy to demo, but unattended execution inside a real repo breaks on environment drift, hidden dependencies, bad tests, and permission boundaries. OpenAI is clearly aiming at that gap, not at autocomplete.

I buy one design choice here: AGENTS.md. That is a very practical control surface. Put instructions in-repo, tell the agent how to navigate, which commands to run, and which conventions matter. This lines up with what the rest of the market has been learning the hard way. Claude Code, Cursor’s agent features, Devin, Copilot Workspace — all of them discovered that model quality alone does not decide success on real work. Test reliability, repo-specific instructions, tool permissions, and environment setup decide a lot more than benchmark screenshots do. OpenAI saying the agent performs best with a configured dev environment and clear documentation is one of the more honest lines in the post.

That said, I have two big reservations.

First, the benchmark disclosure is thin. The post says codex-1 is a version of o3 optimized for software engineering. It says 23 SWE-Bench Verified samples that were not runnable on OpenAI’s internal infrastructure were excluded. It says testing used 192k context and medium reasoning effort. That is useful, but it is still not enough for clean comparison. How much did the exclusions affect the score? Not disclosed. How does Codex compare against Claude Code or Cursor on real private repos with ugly setup scripts and flaky tests? Not disclosed. The internal SWE benchmark is curated and internal. I am not saying Codex underperforms. I am saying OpenAI has not given enough here to claim that it has set the engineering standard for code agents.

Second, the business model is still blurry, and that matters a lot more here than in chat products. The article excerpt points to availability, pricing, and limitations, but the full details are not present in the material provided. We do not have complete pricing, concurrency caps, quota structure, or default network policy from the main body here. That is a major omission. A code agent that spins sandboxes, runs builds, and executes tests does not behave like a plain token-metered chatbot. Compute cost, queue management, and abuse handling all get harder. OpenAI’s rollout order — Pro, Business, Enterprise first, then Plus on June 3 — already hints that they know this is not cheap.

The June 3 update is also more consequential than it looks. OpenAI added internet access during task execution. That will improve success rates on dependency fetches, documentation lookup, and integration tasks. It also raises the reproducibility and supply-chain risk profile. If an agent can reach the network, then the audit model has to be much tighter. The post excerpt we have is truncated before the full safety section, so I cannot verify the exact controls from this material alone. That uncertainty matters.

There is also a market-structure angle here that I think is easy to miss. OpenAI did not launch Codex as a standalone developer product first. It put it in the ChatGPT sidebar. That is classic OpenAI distribution logic: use the existing surface, then fold higher-value agent behavior into the subscription stack. For developer-tool companies, the threat is not just “OpenAI entered coding again.” The threat is that workflow capture moves upstream into the user’s default AI interface. If that happens, independent tools need a sharper wedge. Cursor keeps an IDE-native experience and fast iteration. Devin pushes harder on autonomy. GitHub keeps source-control gravity and enterprise seats. Codex is entering the middle of that map, and the middle is crowded.

So my read is: the direction is right, and the product shape is much more serious than another code-demo release. But this still looks like OpenAI staking out the managed code-agent layer, not ending the category. I would judge it on three things that are still underspecified in the provided material: pricing, concurrency limits, and production outcomes on messy real repos — rollback rate, human takeover rate, and how often the “verifiable evidence” actually corresponds to useful changes rather than busywork. Until those numbers are public, I’m not buying any victory lap.

Aug 13, 2024Tuesday

OpenAI NewsAug 13, 18:00

Introducing SWE-bench Verified

OpenAI released SWE-bench Verified, a human-validated subset built with the benchmark’s authors to assess real software issue resolution more reliably. The post names 3 failure modes in SWE-bench: overly narrow tests, underspecified issue statements, and unreliable environment setup; as of Aug. 5, 2024, top agents scored about 20% on SWE-bench and 43% on SWE-bench Lite. The key point is that the original benchmark can systematically underestimate coding-agent ability.

Why it matters: This is a strong benchmark release, not a routine post: OpenAI re-audited SWE-bench with the original authors, named 3 defect classes, and reported new score ceilings of 20% and 43%. HKR-H/K/R all pass because it changes how builders read code-agent leaderboards.

Take

OpenAI is pulling SWE-bench back from leaderboard theater into risk evaluation. The original set spans 12 Python repos, and the top agents sat around 20% on SWE-bench and 43% on Lite as of Aug. 5, 2024. That reads like weak coding agents. The post names three benchmark defects: narrow tests, underspecified issues, and unreliable environments. Those defects reject valid patches and mislabel harness failure as model failure.

I buy this move more than another model claiming a few extra points. SWE-bench Verified is a human-validated subset built with the benchmark authors, and it fits OpenAI’s Preparedness Framework for Model Autonomy. Cursor, Devin, and Claude Code live on long-loop debugging and environment recovery, not clean single-shot pass rates. The old SWE-bench was partly blind to that.