예약된 작업

반복 작업이 백그라운드에서 실행되도록 예약하세요. Scheduled에서 활성 상태, 일시 중지 상태, 완료된 작업과 최근 실행을 검토할 수 있습니다. 더 복잡한 작업을 위해 예약된 작업을 skills와 결합할 수도 있습니다.

ChatGPT 데스크톱 앱

ChatGPT 데스크톱 앱에서 예약된 작업은 로컬 프로젝트를 대상으로 실행할 수 있으며, 프로젝트 디렉터리나 격리된 worktree에서 실행됩니다. 예약된 작업에 로컬 파일이 필요한 경우 컴퓨터를 켜 두고 앱을 실행해 두세요.

ChatGPT 웹

워크스페이스에서 예약된 작업이 활성화되어 있으면 웹의 Chat 또는 ChatGPT Work에서 작업을 만들고 Scheduled에서 실행을 관리할 수 있습니다. 웹 작업은 업로드된 컨텍스트와 연결된 도구를 사용할 수 있지만, 컴퓨터의 폴더에서 직접 작업할 수는 없습니다.

Codex CLI

Codex CLI는 Scheduled 관리 인터페이스를 제공하지 않습니다. ChatGPT 웹이나 데스크톱 앱에서 예약된 작업을 만들고 관리하세요. CLI를 사용하여 먼저 프롬프트, skill 또는 스크립트를 준비하고 테스트할 수 있습니다.

IDE 확장 프로그램

IDE 확장 프로그램은 Scheduled 관리 인터페이스를 제공하지 않습니다. ChatGPT 웹이나 데스크톱 앱에서 예약된 작업을 만들고 관리하세요. IDE 확장 프로그램을 사용하여 먼저 프롬프트, skill 또는 워크스페이스 변경 사항을 준비하고 테스트할 수 있습니다.

웹에서 예약된 작업 관리하기

Scheduled를 열어 작업 상태와 최근 실행을 검토하세요. 각 실행이 저장된 프롬프트에서 시작해야 한다면 독립형 예약 작업을 사용하세요. ChatGPT가 기존 컨텍스트가 있는 동일한 채팅으로 돌아오게 하려면 채팅 내 예약 작업을 사용하세요.

웹의 예약된 작업은 해당 채팅에서 사용할 수 있는 업로드된 파일, 연결된 도구, skills 및 plugins를 사용할 수 있습니다. 실행 사이에 로컬 폴더나 worktree를 유지하지는 않습니다. 지속적으로 적용할 지침은 작업 프롬프트나 첨부된 skill에 넣고, 필요한 소스 자료는 접근 가능한 프로젝트, 업로드 또는 연결된 서비스에 보관하세요.

작업을 예약하기 전에 일반 웹 채팅에서 프롬프트를 테스트하세요. 처음 몇 번의 실행을 검토한 다음 결과의 범위가 너무 넓거나 추가 컨텍스트가 필요한 경우 프롬프트, 도구 또는 실행 주기를 조정하세요.

ChatGPT 데스크톱 앱

예를 들어 원격 분석 오류를 평가하고 수정 사항을 제출하거나 최근 코드베이스 변경 사항에 관한 보고서를 작성하는 작업을 예약할 수 있습니다. 동일한 컨텍스트를 계속 사용해야 하는 진행 중인 작업의 경우 기존 채팅 내에서 작업을 예약하세요.

프로젝트 범위의 예약된 작업을 사용하려면 컴퓨터를 켜 두고 ChatGPT 데스크톱 앱을 실행해 두세요. 작업이 실행되도록 예약된 시점에도 선택한 프로젝트가 디스크에 있어야 합니다.

Git 저장소에서는 예약된 작업을 로컬 프로젝트에서 실행할지 새 worktree에서 실행할지 선택할 수 있습니다. 두 옵션 모두 백그라운드에서 실행됩니다. worktree를 사용하면 예약된 작업의 변경 사항을 완료되지 않은 로컬 작업과 분리할 수 있지만, 로컬 프로젝트에서 실행하면 현재 작업 중인 파일이 수정될 수 있습니다. 버전 관리되지 않는 프로젝트에서는 예약된 작업이 프로젝트 디렉터리에서 직접 실행됩니다.

모델과 추론 수준을 기본 설정으로 둘 수도 있고, 예약된 작업의 실행 방식을 더 세밀하게 제어하려면 명시적으로 선택할 수도 있습니다.

예약된 작업에서 ChatGPT 로그인과 함께 gpt-5.4 또는 gpt-5.4-mini을 사용하는 경우, 해당 모델이 2026년 8월 31일에 지원 종료되기 전에 업데이트하세요. gpt-5.4을 gpt-5.6-terra으로, gpt-5.4-mini을 gpt-5.6-luna으로 교체하세요.

예약된 작업은 기본 샌드박스 설정을 사용하여 사용자 개입 없이 실행됩니다. 작업을 성공적으로 수행할 수 있는 가장 제한적인 액세스 권한으로 시작하고, 필요한 경우에만 네트워크 또는 더 광범위한 파일 액세스 권한을 부여하세요. 샌드박싱 이해하기.

예약된 작업 관리하기

ChatGPT 데스크톱 앱 사이드바의 Scheduled에서 모든 예약된 작업과 실행 내역을 확인할 수 있습니다.

Scheduled 보기는 받은 편지함 역할을 합니다. 확인할 결과가 있는 예약된 작업 실행이 여기에 표시되며, 실행에 주의가 필요한 경우 읽지 않음 표시가 나타납니다.

독립형 예약 작업은 예약된 실행마다 새 채팅을 시작하고 결과를 Scheduled에 보고합니다. 각 실행이 독립적이어야 하거나 하나의 예약된 작업을 하나 이상의 프로젝트에서 실행해야 하는 경우 사용하세요. 사용자 지정 주기가 필요하면 사용자 지정 일정 제어 기능을 사용하세요. 고급 일정의 경우 RFC 5545 반복 규칙(RRULE)을 편집하세요. 예: RRULE:FREQ=MONTHLY;BYMONTHDAY=1;BYHOUR=9;BYMINUTE=0.

Git 저장소에서는 각 예약된 작업을 로컬 프로젝트 또는 전용 백그라운드 worktree에서 실행할 수 있습니다. 예약된 작업의 변경 사항을 완료되지 않은 로컬 작업과 격리하려면 worktree를 사용하세요. 예약된 작업이 기본 checkout에서 직접 작업하도록 하려면 로컬 모드를 사용하되, 현재 편집 중인 파일을 변경할 수 있다는 점에 유의하세요. 버전 관리되지 않는 프로젝트에서는 예약된 작업이 프로젝트 디렉터리에서 직접 실행됩니다. 동일한 예약된 작업을 둘 이상의 프로젝트에서 실행할 수도 있습니다.

웹의 ChatGPT Work 또는 데스크톱 앱의 ChatGPT Work나 Codex에서 만든 예약된 작업은 plugins를 사용할 수 있습니다. 예약된 작업은 skills도 사용할 수 있습니다. 팀 전체에서 예약된 작업을 쉽게 유지 관리하고 공유하려면 skills를 사용하여 작업을 정의하고 도구와 컨텍스트를 제공하세요. 워크플로가 자동 도구 선택에 의존해서는 안 되는 경우 작업 프롬프트에서 특정 skill을 선택하거나 호출하세요.

ChatGPT에 예약된 작업 생성 또는 업데이트 요청하기

ChatGPT 또는 Codex 채팅에서 예약된 작업을 생성하고 업데이트할 수 있습니다. 작업 내용과 일정, 그리고 예약된 각 실행이 현재 채팅으로 돌아와야 하는지 새 채팅을 시작해야 하는지 설명하세요. ChatGPT는 프롬프트 초안을 작성하고 적절한 대상을 선택하며, 범위나 주기가 변경되면 예약된 작업을 업데이트할 수 있습니다.

예를 들어 배포가 완료되는 동안 현재 채팅에서 후속 확인을 예약해 달라고 ChatGPT에 요청하거나, 프로젝트를 반복 일정에 따라 확인하는 독립형 예약 작업을 만들어 달라고 요청할 수 있습니다.

Skills도 예약된 작업을 생성하거나 업데이트할 수 있습니다. 예를 들어 pull request를 지속적으로 관리하는 skill은 GitHub plugin으로 PR 상태를 확인하고 새로운 검토 의견을 수정하는 예약된 작업을 설정할 수 있습니다.

채팅 내에서 작업 예약하기

ChatGPT가 일정에 따라 해당 채팅으로 돌아오게 하려면 기존 채팅 내에서 작업을 예약하세요. 예약된 작업은 매번 새 프롬프트에서 시작하는 대신 채팅의 기존 컨텍스트를 사용합니다.

채팅 내 예약된 작업은 능동적인 후속 확인 루프를 위해 분 단위 간격을 사용하거나, 특정 시각에 확인해야 할 때 일간 및 주간 일정을 사용할 수 있습니다.

다음과 같은 경우 채팅 내에서 작업을 예약하세요.

• 장시간 실행되는 작업이 완료될 때까지 확인
• 결과를 동일한 채팅에 유지해야 할 때 Slack, GitHub 또는 기타 연결된 소스 폴링
• ChatGPT가 고정된 주기로 검토 루프를 계속하도록 알림
• PR 상태 확인 및 새로운 피드백 반영과 같이 plugins를 사용하는 skill 기반 워크플로 실행
• 컨텍스트를 잃지 않고 진행 중인 조사 또는 분류 채팅 계속하기

각 실행이 독립적이어야 하거나 결과가 Scheduled에 별도의 실행으로 표시되어야 하는 경우 독립형 예약 작업을 사용하세요.

채팅 내에서 작업을 예약할 때는 프롬프트가 지속적으로 유효하도록 작성하세요. 예약된 각 실행에서 ChatGPT가 수행해야 할 작업, 보고할 중요한 내용이 있는지 판단하는 방법, 그리고 언제 중지하거나 사용자 입력을 요청해야 하는지를 설명해야 합니다.

예약된 작업 테스트하기

작업을 예약하기 전에 먼저 일반 채팅에서 프롬프트를 수동으로 테스트하세요. 이를 통해 다음 사항을 확인할 수 있습니다.

• 프롬프트가 명확하고 범위가 올바르게 설정되어 있습니다.
• 선택한 모델 또는 기본 모델, 추론 수준 및 도구가 예상대로 작동합니다.
• 결과 출력을 검토할 수 있습니다.

실행 예약을 시작하면 처음 몇 개의 출력을 검토하고 필요에 따라 프롬프트나 주기를 조정하세요.

ChatGPT 데스크톱 앱에서는 $skill-name을 사용하여 예약된 작업 프롬프트에서 skill을 명시적으로 호출할 수 있습니다.

예약된 작업의 worktree 정리

Git 저장소에 worktree를 사용하도록 선택하면 실행 주기가 잦을수록 시간이 지나면서 많은 worktree가 생성될 수 있습니다. 더 이상 필요하지 않은 예약 실행은 보관 처리하고, worktree를 유지할 의도가 없다면 실행을 고정하지 마세요.

권한 및 보안 모델

예약된 작업은 기본 샌드박스 설정을 사용하여 사용자 개입 없이 실행됩니다.

이러한 경계를 쉽게 설명한 내용은 샌드박싱 개요를 참조하세요. 파일 시스템 및 네트워크 규칙은 권한을 참조하세요.

• 샌드박스 모드가 읽기 전용이면 파일 수정, 네트워크 액세스 또는 컴퓨터의 앱 사용이 필요한 도구 호출은 실패합니다. 샌드박스 설정을 워크스페이스 쓰기로 변경하는 것을 고려하세요.
• 샌드박스 모드가 워크스페이스 쓰기이면 워크스페이스 외부의 파일 수정, 네트워크 액세스 또는 컴퓨터의 앱 사용이 필요한 도구 호출은 실패합니다. 규칙을 사용하여 샌드박스 외부에서 실행할 명령을 선택적으로 허용 목록에 추가할 수 있습니다.
• 샌드박스 모드가 전체 액세스이면 ChatGPT가 확인을 요청하지 않고 파일을 변경하고, 명령을 실행하며, 네트워크에 액세스할 수 있으므로 백그라운드 예약 작업의 위험이 커집니다. 샌드박스 설정을 워크스페이스 쓰기로 변경하고, 규칙을 사용하여 에이전트가 전체 액세스 권한으로 실행할 수 있는 명령을 선택적으로 정의하는 것을 고려하세요.

관리형 환경을 사용하는 경우 관리자는 관리자가 강제하는 요구 사항으로 이러한 동작을 제한할 수 있습니다. 예를 들어 approval_policy = "never"를 허용하지 않거나 사용할 수 있는 샌드박스 모드를 제한할 수 있습니다. 관리자가 강제하는 요구 사항(requirements.toml)을 참조하세요.

조직 정책에서 허용하는 경우 예약된 작업은 approval_policy = "never"을 사용합니다. 관리자 요구 사항에서 approval_policy = "never"을 허용하지 않으면 예약된 작업은 선택한 권한 모드의 승인 동작으로 대체됩니다.

예시

새 skills 자동 생성하기

Scan all of the `~/.codex/sessions` files from the past day and if there have been any issues using particular skills, update the skills to be more helpful. Personal skills only, no repo skills.

If there’s anything we’ve been doing often and struggle with that we should save as a skill to speed up future work, let’s do it.

Definitely don't feel like you need to update any- only if there's a good reason!

Let me know if you make any.

프로젝트의 최신 상태 유지하기

Look at the latest remote origin/master or origin/main . Then produce an exec briefing for the last 24 hours of commits that touch <DIRECTORY>

Formatting + structure:

- Use rich Markdown (H1 workstream sections, italics for the subtitle, horizontal rules as needed).
- Preamble can read something like “Here’s the last 24h brief for <directory>:”
- Subtitle should read: “Narrative walkthrough with owners; grouped by workstream.”
- Group by workstream rather than listing each commit. Workstream titles should be H1.
- Write a short narrative per workstream that explains the changes in plain language.
- Use bullet points and bolding when it makes things more readable
- Feel free to make bullets per person, but bold their name

Content requirements:

- Include PR links inline (e.g., [#123](...)) without a “PRs:” label.
- Do NOT include commit hashes or a “Key commits” section.
- It’s fine if multiple PRs appear under one workstream, but avoid per‑commit bullet lists.

Scope rules:

- Only include changes within the current cwd (or main checkout equivalent)
- Only include the last 24h of commits.
- Use `gh` to fetch PR titles and descriptions if it helps.
  Also feel free to pull PR reviews and comments

예약된 작업과 스킬을 결합하여 직접 버그 수정하기

직접 만든 커밋에서 발생한 버그를 수정하기 위해 새로운 $recent-code-bugfix을(를) 생성하는 스킬을 만들고 개인 스킬에 저장합니다.

---
name: recent-code-bugfix
description: Find and fix a bug introduced by the current author within the last week in the current working directory. Use when a user wants a proactive bugfix from their recent changes, when the prompt is empty, or when asked to triage/fix issues caused by their recent commits. Root cause must map directly to the author’s own changes.
---

# Recent Code Bugfix

## Overview

Find a bug introduced by the current author in the last week, implement a fix, and verify it when possible. Operate in the current working directory, assume the code is local, and ensure the root cause is tied directly to the author’s own edits.

## Workflow

### 1) Establish the recent-change scope

Use Git to identify the author and changed files from the last week.

- Determine the author from `git config user.name`/`user.email`. If unavailable, use the current user’s name from the environment or ask once.
- Use `git log --since=1.week --author=<author>` to list recent commits and files. Focus on files touched by those commits.
- If the user’s prompt is empty, proceed directly with this default scope.

### 2) Find a concrete failure tied to recent changes

Prioritize defects that are directly attributable to the author’s edits.

- Look for recent failures (tests, lint, runtime errors) if logs or CI outputs are available locally.
- If no failures are provided, run the smallest relevant verification (single test, file-level lint, or targeted repro) that touches the edited files.
- Confirm the root cause is directly connected to the author’s changes, not unrelated legacy issues. If only unrelated failures are found, stop and report that no qualifying bug was detected.

### 3) Implement the fix

Make a minimal fix that aligns with project conventions.

- Update only the files needed to resolve the issue.
- Avoid adding extra defensive checks or unrelated refactors.
- Keep changes consistent with local style and tests.

### 4) Verify

Attempt verification when possible.

- Prefer the smallest validation step (targeted test, focused lint, or direct repro command).
- If verification cannot be run, state what would be run and why it wasn’t executed.

### 5) Report

Summarize the root cause, the fix, and the verification performed. Make it explicit how the root cause ties to the author’s recent changes.

그런 다음 새 예약 작업을 만듭니다.

Check my commits from the last 24h and submit a $recent-code-bugfix.