Merge commit 'a34da3b2'

Author: Lee Penkman

.bazelrc

@@ -38,24 +38,50 @@ common:windows --test_env=WINDIR
 common --test_env=RUST_MIN_STACK=8388608 # 8 MiB
 
 common --test_output=errors
-common --bes_results_url=https://app.buildbuddy.io/invocation/
-common --bes_backend=grpcs://remote.buildbuddy.io
-common --remote_cache=grpcs://remote.buildbuddy.io
-common --remote_download_toplevel
 common --nobuild_runfile_links
+# These settings tune BuildBuddy/RBE behavior but do not contact a remote
+# service unless a `buildbuddy-*` configuration below supplies an endpoint.
+common --remote_download_toplevel
 common --remote_timeout=3600
 common --noexperimental_throttle_remote_action_building
 common --experimental_remote_execution_keepalive
 common --grpc_keepalive_time=30s
-common --experimental_remote_downloader=grpcs://remote.buildbuddy.io
+
+# Opt-in remote configurations selected by
+# `.github/scripts/run_bazel_with_buildbuddy.py`. Plain Bazel commands do not
+# contact BuildBuddy unless a user selects one of these configurations.
+# Use the generic host for cache, BES, and downloads without remote execution.
+common:buildbuddy-generic --bes_backend=grpcs://remote.buildbuddy.io
+common:buildbuddy-generic --bes_results_url=https://app.buildbuddy.io/invocation/
+common:buildbuddy-generic --remote_cache=grpcs://remote.buildbuddy.io
+common:buildbuddy-generic --experimental_remote_downloader=grpcs://remote.buildbuddy.io
+
+# Add remote execution on the generic host.
+common:buildbuddy-generic-rbe --config=buildbuddy-generic
+common:buildbuddy-generic-rbe --config=remote
+common:buildbuddy-generic-rbe --remote_executor=grpcs://remote.buildbuddy.io
+
+# Use the OpenAI tenant for cache, BES, and downloads without remote execution.
+common:buildbuddy-openai --bes_backend=grpcs://openai.buildbuddy.io
+common:buildbuddy-openai --bes_results_url=https://openai.buildbuddy.io/invocation/
+common:buildbuddy-openai --remote_cache=grpcs://openai.buildbuddy.io
+common:buildbuddy-openai --experimental_remote_downloader=grpcs://openai.buildbuddy.io
+
+# Add remote execution on the OpenAI tenant.
+common:buildbuddy-openai-rbe --config=buildbuddy-openai
+common:buildbuddy-openai-rbe --config=remote
+common:buildbuddy-openai-rbe --remote_executor=grpcs://openai.buildbuddy.io
 
 # This limits both in-flight executions and concurrent downloads. Even with high number
 # of jobs execution will still be limited by CPU cores, so this just pays a bit of
 # memory in exchange for higher download concurrency.
 common --jobs=30
 
+# Shared remote execution policy. The endpoint-bearing `buildbuddy-*-rbe`
+# configurations include this group; CI configs override TestRunner below
+# when tests must remain local on their runner.
+common:remote --strategy=remote
 common:remote --extra_execution_platforms=//:rbe
-common:remote --remote_executor=grpcs://remote.buildbuddy.io
 common:remote --jobs=800
 # TODO(team): Evaluate if this actually helps, zbarsky is not sure, everything seems bottlenecked on `core` either way.
 # Enable pipelined compilation since we are not bound by local CPU count.
@@ -142,23 +168,17 @@ common:ci-windows --repo_contents_cache=D:/a/.cache/bazel-repo-contents-cache
 # Linux crossbuilds don't work until we untangle the libc constraint mess.
 common:ci-linux --config=ci-bazel
 common:ci-linux --build_metadata=TAG_os=linux
-common:ci-linux --config=remote
-common:ci-linux --strategy=remote
 common:ci-linux --platforms=//:rbe
 
 # On mac, we can run all the build actions remotely but test actions locally.
 common:ci-macos --config=ci-bazel
 common:ci-macos --build_metadata=TAG_os=macos
-common:ci-macos --config=remote
-common:ci-macos --strategy=remote
 common:ci-macos --strategy=TestRunner=darwin-sandbox,local
 
 # Linux-only V8 CI config.
 common:ci-v8 --config=ci
 common:ci-v8 --build_metadata=TAG_workflow=v8
 common:ci-v8 --build_metadata=TAG_os=linux
-common:ci-v8 --config=remote
-common:ci-v8 --strategy=remote
 
 # Optional per-user local overrides.
 try-import %workspace%/user.bazelrc

.codex/environments/setup.py

@@ -0,0 +1,65 @@
+#!/usr/bin/env python3
+
+"""Set up ignored files that should be shared with Codex worktrees."""
+
+import shutil
+import subprocess
+from functools import cache
+from pathlib import Path
+
+
+@cache
+def worktree_paths() -> tuple[Path, Path]:
+    script_dir = Path(__file__).resolve().parent
+    worktree_root = git_path(script_dir / "../..", "--show-toplevel")
+    common_git_dir = git_path(worktree_root, "--git-common-dir")
+    return worktree_root, common_git_dir.parent
+
+
+def git_path(working_directory: Path, argument: str) -> Path:
+    output = subprocess.check_output(
+        [
+            "git",
+            "-C",
+            str(working_directory),
+            "rev-parse",
+            "--path-format=absolute",
+            argument,
+        ],
+        text=True,
+    )
+    return Path(output.strip())
+
+
+def copy_from_main_worktree_to_worktree(repo_relative_path: str) -> None:
+    relative_path = Path(repo_relative_path)
+    if relative_path.is_absolute() or ".." in relative_path.parts:
+        raise ValueError(f"path must be repository-relative: {repo_relative_path}")
+
+    worktree_root, main_worktree = worktree_paths()
+    source_path = main_worktree / relative_path
+    destination_path = worktree_root / relative_path
+
+    print(f"  source: {source_path}")
+    print(f"  destination: {destination_path}")
+
+    if source_path == destination_path:
+        print("  result: running in the main worktree; nothing to copy")
+    elif destination_path.exists():
+        print("  result: destination already exists; nothing to copy")
+    elif not source_path.is_file():
+        print("  result: source does not exist; nothing to copy")
+    else:
+        destination_path.parent.mkdir(parents=True, exist_ok=True)
+        shutil.copy2(source_path, destination_path)
+        print(f"  result: copied {repo_relative_path}")
+
+
+def main() -> None:
+    print("Codex environment setup:")
+    # See codex-rs/docs/bazel.md for the repository's Bazel workflow.
+    copy_from_main_worktree_to_worktree("user.bazelrc")
+
+
+if __name__ == "__main__":
+    main()

.codex/skills/babysit-pr/SKILL.md

@@ -86,22 +86,51 @@ The watcher surfaces review items from:
 - Inline review comments
 - Review submissions (COMMENT / APPROVED / CHANGES_REQUESTED)
 
+Only act on published feedback. Ignore review submissions in GitHub's `PENDING` state and inline
+comments attached to those pending reviews. Do not mark pending review feedback as seen; it should
+be eligible to surface after the reviewer submits the review.
+
 It intentionally surfaces Codex reviewer bot feedback (for example comments/reviews from `chatgpt-codex-connector[bot]`) in addition to human reviewer feedback. Most unrelated bot noise should still be ignored.
 For safety, the watcher only auto-surfaces trusted human review authors (for example repo OWNER/MEMBER/COLLABORATOR, plus the authenticated operator) and approved review bots such as Codex.
-On a fresh watcher state file, existing pending review feedback may be surfaced immediately (not only comments that arrive after monitoring starts). This is intentional so already-open review comments are not missed.
+On a fresh watcher state file, existing unaddressed published review feedback may be surfaced immediately (not only comments that arrive after monitoring starts). This is intentional so already-open review comments are not missed.
 
 When you agree with a comment and it is actionable:
 
 1. Patch code locally.
 2. Commit with `codex: address PR review feedback (#<n>)`.
 3. Push to the PR head branch.
-4. After the push succeeds, mark the associated GitHub review thread/comment as resolved.
+4. After the push succeeds, resolve the associated GitHub review thread only when allowed by the GitHub state mutation policy below.
 5. Resume watching on the new SHA immediately (do not stop after reporting the push).
 6. If monitoring was running in `--watch` mode, restart `--watch` immediately after the push in the same turn; do not wait for the user to ask again.
 
 If you disagree or the comment is non-actionable/already addressed, reply once directly on the GitHub comment/thread so the reviewer gets an explicit answer, then continue the watcher loop. Prefix any GitHub reply to a code review comment/thread with `[codex]` so it is clear the response is automated and not from the human user. If the watcher later surfaces your own reply because the authenticated operator is treated as a trusted review author, treat that self-authored item as already handled and do not reply again.
 If a code review comment/thread is already marked as resolved in GitHub, treat it as non-actionable and safely ignore it unless new unresolved follow-up feedback appears.
 
+## GitHub State Mutation Policy
+
+You can read any PR state you need for monitoring. Writes must comply with this policy.
+
+You can push PRs to update the code under review or to force CI re-runs as described above.
+
+You can resolve review comment threads from the human who requested babysitting or from the Codex
+review bot. When resolving, leave a comment prefixed with `[from Codex]: ` and explain what changes
+you made and which commit includes them. Don't touch review threads if other humans other than the
+user who requested babysitting have participated.
+
+Before making any changes, fetch the PR state yourself instead of relying on the PR watcher script's
+output.
+
+Unless explicitly asked, do not:
+
+* comment on other humans' review threads, communicate with the user in chat instead
+* resolve review threads from humans other than the user
+* interact with humans other than the user
+* mark PRs as drafts or ready for review
+* close or reopen PRs
+
+In general, never act on GitHub in ways that would make it hard to tell whether you or the user did
+something visible to other humans. When in doubt, ask the user for clarification in chat.
+
 ## Git Safety Rules
 
 - Work only on the PR head branch.

.codex/skills/babysit-pr/references/github-api-notes.md

@@ -42,6 +42,9 @@ Reruns only failed jobs (and dependencies) for a workflow run.
 - Review submissions:
   - `gh api repos/{owner}/{repo}/pulls/<pr_number>/reviews?per_page=100`
 
+Use each inline comment's `pull_request_review_id` to find its parent review. Ignore parent reviews
+whose `state` is `PENDING`, along with their inline comments, until the review is submitted.
+
 ## JSON fields consumed by the watcher
 
 ### `gh pr view`

.codex/skills/babysit-pr/scripts/gh_pr_watch.py

@@ -392,11 +392,14 @@ def normalize_issue_comments(items):
     return out
 
 
-def normalize_review_comments(items):
+def normalize_review_comments(items, review_states):
     out = []
     for item in items:
         if not isinstance(item, dict):
             continue
+        review_id = str(item.get("pull_request_review_id") or "")
+        if review_states.get(review_id) == "PENDING":
+            continue
         line = item.get("line")
         if line is None:
             line = item.get("original_line")
@@ -421,6 +424,8 @@ def normalize_reviews(items):
     for item in items:
         if not isinstance(item, dict):
             continue
+        if str(item.get("state") or "").upper() == "PENDING":
+            continue
         out.append(
             {
                 "kind": "review",
@@ -474,16 +479,33 @@ def fetch_new_review_items(pr, state, fresh_state, authenticated_login=None):
     review_payload = gh_api_list_paginated(endpoints["review"], repo=repo)
 
     issue_items = normalize_issue_comments(issue_payload)
-    review_comment_items = normalize_review_comments(review_comment_payload)
+    review_states = {
+        str(item.get("id")): str(item.get("state") or "").upper()
+        for item in review_payload
+        if isinstance(item, dict) and item.get("id") not in (None, "")
+    }
+    pending_review_ids = {
+        review_id for review_id, review_state in review_states.items() if review_state == "PENDING"
+    }
+    pending_review_comment_ids = {
+        str(item.get("id"))
+        for item in review_comment_payload
+        if isinstance(item, dict)
+        and item.get("id") not in (None, "")
+        and str(item.get("pull_request_review_id") or "") in pending_review_ids
+    }
+    review_comment_items = normalize_review_comments(review_comment_payload, review_states)
     review_items = normalize_reviews(review_payload)
     all_items = issue_items + review_comment_items + review_items
 
     seen_issue = {str(x) for x in state.get("seen_issue_comment_ids") or []}
     seen_review_comment = {str(x) for x in state.get("seen_review_comment_ids") or []}
     seen_review = {str(x) for x in state.get("seen_review_ids") or []}
+    seen_review_comment.difference_update(pending_review_comment_ids)
+    seen_review.difference_update(pending_review_ids)
 
     # On a brand-new state file, surface existing review activity instead of
-    # silently treating it as seen. This avoids missing already-pending review
+    # silently treating it as seen. This avoids missing already-published review
     # feedback when monitoring starts after comments were posted.
 
     new_items = []

.codex/skills/babysit-pr/scripts/test_gh_pr_watch.py

@@ -112,6 +112,74 @@ def test_recommend_actions_prioritizes_review_comments():
     ]
 
 
+def test_pending_review_feedback_surfaces_only_after_publication(monkeypatch):
+    state = {
+        "seen_review_comment_ids": ["20"],
+        "seen_review_ids": ["10"],
+    }
+    review = {
+        "id": 10,
+        "user": {"login": "octocat"},
+        "author_association": "MEMBER",
+        "state": "PENDING",
+        "body": "Please rename this.",
+        "created_at": "2026-06-08T10:00:00Z",
+        "submitted_at": None,
+        "html_url": "https://github.com/openai/codex/pull/123#pullrequestreview-10",
+    }
+    review_comment = {
+        "id": 20,
+        "pull_request_review_id": 10,
+        "user": {"login": "octocat"},
+        "author_association": "MEMBER",
+        "body": "Please rename this.",
+        "created_at": "2026-06-08T10:00:00Z",
+        "path": "src/example.rs",
+        "line": 7,
+        "html_url": "https://github.com/openai/codex/pull/123#discussion_r20",
+    }
+
+    def fake_list(endpoint, **kwargs):
+        if endpoint.endswith("/issues/123/comments"):
+            return []
+        if endpoint.endswith("/pulls/123/comments"):
+            return [review_comment]
+        if endpoint.endswith("/pulls/123/reviews"):
+            return [review]
+        raise AssertionError(f"unexpected endpoint: {endpoint}")
+
+    monkeypatch.setattr(gh_pr_watch, "gh_api_list_paginated", fake_list)
+
+    assert (
+        gh_pr_watch.fetch_new_review_items(
+            sample_pr(),
+            state,
+            fresh_state=True,
+            authenticated_login="octocat",
+        )
+        == []
+    )
+    assert state["seen_review_comment_ids"] == []
+    assert state["seen_review_ids"] == []
+
+    review["state"] = "COMMENTED"
+    review["submitted_at"] = "2026-06-08T10:05:00Z"
+
+    published_items = gh_pr_watch.fetch_new_review_items(
+        sample_pr(),
+        state,
+        fresh_state=False,
+        authenticated_login="octocat",
+    )
+
+    assert {(item["kind"], item["id"]) for item in published_items} == {
+        ("review", "10"),
+        ("review_comment", "20"),
+    }
+    assert state["seen_review_comment_ids"] == ["20"]
+    assert state["seen_review_ids"] == ["10"]
+
+
 def test_run_watch_keeps_polling_open_ready_to_merge_pr(monkeypatch):
     sleeps = []
     events = []

.codex/skills/codex-pr-body/SKILL.md

@@ -19,6 +19,8 @@ Limit discussion to the _net change_ of the commit. It is generally frowned upon
 
 Avoid references to absolute paths on my local disk. When talking about a path that is within the repository, simply use the repo-relative path.
 
+Avoid references to confidential information including but not limited to codenames or OpenAI-internal URLs.
+
 It is generally helpful to discuss how the change was verified. That said, it is unnecessary to mention things that CI checks automatically, e.g., do not include "ran `just fmt`" as part of the test plan. Though identifying the new tests that were purposely introduced to verify the new behavior introduced by the pull request is often appropriate.
 
 Make use of Markdown to format the pull request professionally. Ensure "code things" appear in single backticks when referenced inline. Fenced code blocks are useful when referencing code or showing a shell transcript. Also, make use of GitHub permalinks when citing existing pieces of code that are relevant to the change.