The bits that
keep breaking.

Why this notebook exists

This started with ordinary work: Keep a progress graphic up to date, post useful staff updates, and repeat a few established tasks without needing me to supervise every step.

I use two dots. Both have been useful, and both have been unreliable in ways that are hard to diagnose. I have spent too much time repeating permissions, rescuing browser sessions, and trying to understand why something that worked last week stopped working today.

The skill library is one response to that. The other is this notebook. I want a place to share useful methods without pretending the process was smooth or the product is more dependable than my experience supports.

These are my observations, not a controlled reliability benchmark. The Slack incident below has a public, dated report. The broader patterns are my account; I am not presenting a measured failure rate or a diagnosis of OpenAI’s internal systems.

I had already said yes

Much of the recurring work happens in the same three Slack channels. I had explicitly approved the tasks. Nevertheless, my dot kept asking for permission to do the same things again, or stopped at a step it had already completed on earlier runs.

I went back and forth, asked it to create custom rules, checked those rules, and tried to make them address the exact places it kept getting stuck. That eventually helped me make progress. It also made a routine task feel like a negotiation I had to restart every morning.

Custom rules should record a decision once, not become another daily task for the person who made it.

That does not mean every blocked action had the same cause. A destination restriction, an approval-review failure, and a refusal are different things. The assistant needs to explain which one happened. Asking me to repeat permission is not a useful answer when the permission is already there.

OpenAI’s controls guide says a specific instruction can cover future actions within its scope, while other checks still apply. The workflows here ask the dot to reuse that verified scope. They do not ask it to ignore a real denial or expand its own authority.

The progress graphic that became two messages

I wanted one graphic at the top of an existing work channel, updated in the same message each hour. I had reviewed the image and approved the post. I did not want a preliminary text message, an extra reply, or another channel notification only to repeat my approval.

1. The upload got stuck.The attempt ran into destination and approval-review errors. One route was tied to the current conversation rather than the work channel I had requested. An older test destination had not been authorized for that attempt.
2. The assistant made a separate mistake.Before the image was ready, it published a text-only parent message. It later uploaded the graphic as a reply and edited the parent to include it. The integration problems did not justify ignoring the one-post instruction.
3. The first result was not the requested result.The parent eventually displayed the image, but the extra upload reply remained. The recorded sequence took about 20 minutes from the initial request to API readback, including design review. I experienced the overall exchange as almost half an hour. The report does not independently measure notification delivery.
4. A later update found a working route.I explicitly selected a private test channel for the upload. The same bot uploaded the new file there, then changed the existing work-channel message to use it. That update created no new message in the public work channel.

“Staging” means uploading the file somewhere the bot can use before changing the original post. The private upload still created a message in that private channel. It was not silent, and its success did not prove the earlier upload route was fixed.

The final readback confirmed the parent’s image through the API. A signed-in browser view was not available for visual verification. One successful update established a working route for that attempt, not a permanent cure.

Read the full public incident report · Read the later successful-update note

The computer is there. Until it is not.

With both dots, I have repeatedly run into a browser that will not load, a virtual computer that is unreachable, or accounts that have lost the sign-in I already completed. Asking for a reboot has not reliably restored access.

That interrupts more than browsing. A dot cannot honestly verify a page, inspect a delivered graphic, or confirm a staff workflow when it cannot reach the computer it was supposed to use.

I do not know which failures come from the browser, the virtual machine, session persistence, or something else. That uncertainty is part of the problem. “Try signing in again” is not a recovery plan for a computer I cannot reach.

Yesterday’s working task is today’s mystery

I have had scheduled work run reliably for a week or so and then stop, lose the method, or behave as though the established instructions no longer exist. At the same time, my dots sometimes take initiative on things I did not ask for and trip over work I explicitly assigned.

The useful distinction is not “autonomous” versus “careful.” It is whether the assistant acts within the job I approved and can show that it delivered the result.

A saved schedule proves a schedule exists. A completed run does not prove the evidence was checked or the update reached the right place. OpenAI makes that distinction in its tasks and memory guide; the progress and incident playbooks make it part of the completion check.

For repeated failures, keep a dated record of the last success, first observed failure, attempted recovery, and exact blocker. Do not silently disable the schedule, rewrite its purpose, or send the same unhelpful request every day.

Too little to inspect when things fail

The experience feels hermetically sealed. I cannot get the model selection, useful tool trace, or verbose diagnostic output I need to understand why a routine action worked once and failed later. The contrast with the complex work I can get done in Codex makes that especially frustrating.

There is an Activity view; OpenAI’s controls guide describes reviewing progress, files, results, and requests there. That is not the same as having a reproducible diagnostic trail for the failures I am trying to investigate.

I do not need private internal reasoning. I need ordinary debugging information: which task ran, which supported tool or route it used, a safe summary of the input, the result or error, a timestamp, the last successful checkpoint, and what recovery was attempted.

Where that information is available, record it. Where it is not, say so. Do not turn an unexplained failure into a confident story about what must have happened inside the system.

Why I am still experimenting

My willingness to keep testing these tools depends heavily on their being an included experiment rather than something competing with the working allowance I rely on for serious Codex and ChatGPT work. At this level of unpredictability, I would not choose to spend that allowance repeatedly rescuing routine dot tasks.

That is my practical threshold, not a recommendation to depend on them for unattended critical work.

What is worth carrying forward

The improvements that help are concrete: read existing approvals, name the actual destination, prepare the whole post before sending it, preserve a last-good result, and verify what arrived. Treat a failed check as a failed check rather than as progress.

The playful interface is intentional. These helpers can be charming. That should not excuse opaque failures, wasted time, or repeated intervention on already-approved work. The skill shelf and the notebook belong together.

This is an early community sharing experiment. A useful contribution can be a workflow that works, a correction to one that does not, or a clear account of a failure. Include enough context for a stranger to understand the task before pointing them at an issue number.