0 of 3 Articles Published for 3 Days Straight: The 41-Second Timeout Margin That Killed My Automation

A developer built an autonomous Claude Code environment that publishes three affiliate articles daily to Hatena Blog, recovering from a 41-second timeout margin that caused three days of zero publications. The system uses four shell scripts and macOS launchd to run three times a day, with idempotency ensuring the daily publish count converges to three. The developer reports monthly revenue above 1.2M yen from this automation.

For three mornings in a row, my audit log printed the same line: published today: 0 / target: 3 . Nothing crashed. The scripts ran, exited, and produced nothing. The entire cause turned out to be a 41-second margin — a 300-second timeout against a process that actually takes 259 seconds. Changing one number to 600 turned 0/3 into 3/3 the next morning. Some background: I went from earning 100k yen a month as a university student to 600k a month juggling multiple gigs, then lost all of it overnight to a company-initiated layoff. Over the following six months I built an autonomous Claude Code environment, and I'm now above 1.2M yen in monthly revenue. At the core of it is a system that publishes three affiliate articles every morning without a human touching anything. The difference between people who keep earning from affiliate marketing and people who drop out is not writing skill, and not a nose for picking products. It's whether you can keep going . Articles that tend to earn on Rakuten Affiliate share a common pattern: spec-comparison articles about home appliances and gadgets priced above 50,000 yen, with lots of reviews and in stock. Robot vacuums, portable power stations, heat-pump washer-dryers, fully automatic coffee makers. The search intent is "I want to compare before I buy," so product link click-through is high and it fits the structure of affiliate marketing well. The problem is cost. Researching the specs of a high-ticket appliance on the web, building a comparison table, and finishing an article good enough to include the "honestly weak points" section takes 30 to 40 minutes. Three articles is close to two hours. Almost nobody has the willpower to repeat that 365 days a year. I don't either. What you need here isn't "trying harder" — it's an environment that keeps running even when you don't try hard . Once the system is built, the running cost is just API calls. The affiliate-factory I built is a simple structure made of four shell scripts. macOS launchd the successor to cron fires three times a day — morning, midday, and night — and three affiliate articles get published to Hatena Blog every day without any human involvement. There's one more design-level core idea: idempotency . A naive script doesn't care how many articles have already been published today. If the morning batch fails, the day ends at zero. This system first counts "how many were successfully published today" and "how many drafts are left on the Desktop," and generates only the number still missing against the target of three. daily.sh PUB TODAY=$ find "$ARCHIVE" -maxdepth 1 -name "${TODAY} .md" 2 /dev/null | wc -l | tr -d ' ' DRAFTS=$ find "$OUT" -maxdepth 1 -name ' .md' 2 /dev/null | wc -l | tr -d ' ' NEED=$ TARGET - PUB TODAY - DRAFTS "$NEED" -lt 0 && NEED=0 Even if the morning batch is wiped out by API limits, the midday batch calculates "we still need 3 today" and refills. The evening batch fills the last one. No matter how many times it runs, the day's publish count converges to three. Once you understand this design, the roles of the four scripts look completely different. I assume many readers are in the situation of "having to write an article every day is exhausting." I was too. But to be precise, what's exhausting is "making the decision to write an article every day." When the system takes over the decision, the human just looks at the published articles. Here's the structure of the whole system as an ASCII diagram. launchd 毎朝・昼・夜の3回 │ ▼ daily.sh ← 司令塔。冪等に「今日あと何本必要か」を計算 │ ├─ NEED本分ループ ──────────────────────────────────────────┐ │ │ │ generate.sh │ │ │ claude -p + WebSearch で製品を選び記事を生成 │ │ │ timeout 600s / 最大3リトライ │ │ └──→ ~/Desktop/アフィリ記事/YYYY-MM-DD HHMMSS.md ──┘ │ ├─ post-to-hatena.sh --publish --all │ │ Desktop/ .md を blogsync ではてなブログへ全件公開 │ └──→ published/ へアーカイブ（Desktopキューから除去） │ └─ audit-heal.sh │ 壊れ記事の掃除、カバレッジ表の出力、異常時はmacOS通知 └──→ logs/audit-YYYY-MM-DD.log The role of daily.sh is simple. Calculate what's left for today, call generate.sh only as many times as needed, then run publishing and auditing in order. That's it. daily.sh（抜粋） TARGET=3 TODAY="$ date +%Y-%m-%d " PUB TODAY=$ find "$ARCHIVE" -maxdepth 1 -name "${TODAY} .md" 2 /dev/null | wc -l | tr -d ' ' DRAFTS=$ find "$OUT" -maxdepth 1 -name ' .md' 2 /dev/null | wc -l | tr -d ' ' NEED=$ TARGET - PUB TODAY - DRAFTS "$NEED" -lt 0 && NEED=0 if "$NEED" -gt 0 ; then for i in $ seq 1 "$NEED" ; do bash "$DIR/generate.sh" "$i" || echo " daily ⚠ 生成1本失敗（後続の再実行で補充されます）。" done fi bash "$DIR/post-to-hatena.sh" --publish --all bash "$DIR/audit-heal.sh" PUB TODAY counts the files under published/ carrying today's prefix. DRAFTS is the number of drafts still sitting directly on the Desktop. NEED is the difference, clamped to 0 if it goes negative. The important part is that processing doesn't stop when one generate.sh run fails. || echo swallows the error and a later batch refills the remainder. set -uo pipefail is declared at the top, while individual generation failures are absorbed inside the loop. The design keeps the whole flow alive without losing track of what happened. generate.sh is the heart of this system. Using WebSearch, it picks a high-ticket appliance that sells well on Rakuten, researches the specs, and writes the article. Claude does all of that on its own. Prompt structure The prompt is defined in a heredoc inside generate.sh . It instructs Claude through the following steps. The EXCL variable at the top of the prompt holds the list of already-covered products. It's read from posted-products.log and handed to Claude as "do not pick these products this time," so the same product doesn't come up repeatedly. Invoking the claude command generate.sh（抜粋） GEN TIMEOUT="${AFFILIATE FACTORY GEN TIMEOUT:-600}" for attempt in 1 2 3; do RESP=$ timeout "$GEN TIMEOUT" "$CLAUDE" -p "$PROMPT" \ --allowedTools WebSearch \ --model sonnet \ --permission-mode auto \ </dev/null 2 /dev/null if resp is valid "$RESP"; then break; fi echo " generate 生成失敗 試行${attempt}/3 。再試行します…" &2 RESP="" done Each of these three flags exists for a reason. </dev/null — a process launched from launchd has no tty. Without this, claude -p keeps waiting on stdin and hangs. It's a trap you never notice when running manually from a terminal; it only reproduces under launchd. --permission-mode auto — when using WebSearch, Claude normally asks for confirmation to use it. If that prompt appears in an environment with no tty, it hangs with no response ever returning. Specifying auto makes the tools allowed via --allowedTools execute without confirmation. timeout 600 — this is the main story. The flow of generating an article while running WebSearch multiple times takes about 260 seconds in practice. I originally set it to 300 seconds. And for the first three days, nothing got published at all. I cover the cause and the permanent fix in detail later in this article. Generating Rakuten affiliate links The other important job of generate.sh is embedding Rakuten affiliate links correctly. The "search on Rakuten" links Claude writes into the article don't carry affiliate tracking as-is. So the postprocess body function post-processes the body in Python and replaces every Rakuten link Claude wrote. generate.sh（楽天リンク置換） 2 claudeが本文に書いた実リンク 楽天で「…」を探す 任意URL を、正しいアフィリリンクに丸ごと差し替える。 （これをやらないと claude が書いた非アフィリの検索URLがそのまま残る＝報酬ゼロになる） rakuten md link re = re.compile r"\ 楽天で「 ^」 」を探す\ \ ^ \ " body = rakuten md link re.sub lambda m: link, body The links themselves are retrieved via Rakuten's Ichiba Item Search API. However, the Rakuten API has a keyword is not valid error, and passing a product name like "Narwal Freo Z Ultra" verbatim can get rejected. As a countermeasure, the resolve function retries while dropping trailing words one at a time. python generate.sh（楽天API語削り再試行ロジック） def resolve : words = product.split brand = words 0 .lower if words else "" tried = set for n in range len words , 0, -1 : keyword = " ".join words :n .strip if not keyword or keyword in tried: continue tried.add keyword result = fetch keyword if result: if not brand or brand in result "name" + " " + result "url" .lower : return result "url" ブランド不一致=別商品に化けた。打ち切り。 return None time.sleep 1.0 return None It tries "Narwal Freo Z Ultra" → "Narwal Freo Z" → "Narwal Freo" in order, and verifies whether the matched product name contains the brand name "narwal" . If it decides the result morphed into a different product, it falls back to a search URL with affiliate tracking an hgc link . Even when an individual product link can't be obtained, the design guarantees a revenue-carrying search link goes in. Posting the article drafts to Hatena Blog is the job of post-to-hatena.sh . The backend is blogsync a Hatena Blog CLI written in Go . post-to-hatena.sh（post one関数） post one { local file="$1" local title body title="$ sed -n 's/^ //p' "$file" | head -1 " -z "$title" && title="$ basename "$file" .md " body="$ awk 'NR==1 && /^ /{next} {print}' "$file" " echo " hatena 投稿: ${DRAFT FLAG:-公開} | $title" printf '%s\n' "$body" | "$BLOGSYNC" post $DRAFT FLAG --title "$title" "$BLOG" } It extracts the first line of the Markdown Title as the entry title and posts the body with the H1 removed. If the H1 stays in the body, Hatena renders it twice. Run with the --publish --all flags, it publishes every draft on the Desktop in one shot and moves published files into the published/ directory, removing them from the Desktop queue. This is so that when the next day's batch counts "drafts left today," yesterday's files don't get mixed in. Posted paths are recorded in posted-hatena.log and used for skip decisions during --all runs. Files listed in the log are excluded from posting, so the same article is never double-posted. Leftovers from failed generation files whose body contains "不明な商品" or "Request timed out" are also detected and skipped before posting. if /usr/bin/grep -qE '不明な商品|Request timed out' "$f"; then echo " hatena スキップ 生成失敗の残骸 : $f" &2; continue fi This is the safety valve that prevents posting a failure file when Claude couldn't produce a decent article even after three attempts. The last step is audit-heal.sh . It runs after the day's publishing finishes and does three things. 1 Cleaning up broken articles It deletes from the queue the failed-generation leftovers that post-to-hatena.sh skipped. for f in "$OUT"/ .md; do -e "$f" || continue if /usr/bin/grep -qE '不明な商品|Request timed out' "$f"; then log " 掃除 壊れ記事を削除: $ basename "$f" " rm -f "$f" fi done 2 Printing a coverage table For every article published today, it verifies that affiliate links are properly included. for f in "$ARCHIVE/${TODAY}" .md; do published=$ published+1 title="$ sed -n 's/^ //p' "$f" | head -1 | cut -c1-30 " if /usr/bin/grep -q 'hb.afl.rakuten.co.jp' "$f"; then link="✓アフィリ" else link="✗非アフィリ"; bad link=$ bad link+1 ; problems=$ problems+1 fi log " ${link} | ${title}" done The decision is made on whether hb.afl.rakuten.co.jp appears in the body. If it doesn't, it's counted as a problem, marked "✗非アフィリ" non-affiliate . A review article published without an affiliate link isn't noticeable to readers, but revenue goes to zero. This is one of the blind spots of automation. 3 macOS notifications If the target count wasn't reached, or if there are articles with non-affiliate links, it fires an alert into macOS Notification Center. notify { command -v osascript /dev/null 2 &1 && \ osascript -e "display notification \"$1\" with title \"アフィリ自動投稿\"" /dev/null 2 &1 || true } When a notification arrives, I check logs/audit-YYYY-MM-DD.log . Which article had the problem and how many were published are both recorded there. The overall audit summary is printed in this format. ==== アフィリ監査 2026-06-22 07:15 ==== --- 本日公開分のカバレッジ --- ✓アフィリ | Roborock S8 MaxV Ultra レビュー... ✓アフィリ | Anker SOLIX C800 ポータブル電源... ✓アフィリ | Narwal Freo Z Ultra 実機スペック... --- サマリ --- 本日公開: 3本 / 目標: 3本 ｜ 未公開キュー残: 0本 ｜ 非アフィリ: 0本 ✅ 監査OK: 3本すべてアフィリリンク付きで公開 This accumulates in logs/ every morning around 7am. The more these logs pile up, the more trust builds that the system is actually running. Later in this article I show, with real code, why audit-heal.sh kept recording "published: 0 / target: 3" for the first three days, and how changing one number fixed it for good. resp is valid protects The resp is valid function at the core of generate.sh is a short four-line implementation, but without it, broken articles pile up on the Desktop. resp is valid { local r="$1" -z "$r" && return 1 printf '%s' "$r" | grep -q '^PRODUCT:' || return 1 printf '%s' "$r" | grep -qiE 'request timed out|error:|rate limit|usage limit' && return 1 "$ printf '%s' "$r" | wc -c | tr -d ' ' " -lt 400 && return 1 return 0 } There are three conditions. ① A PRODUCT: line exists — this is the marker sed uses downstream to extract the product name. Even though the prompt instructs "the first line must contain only PRODUCT: <product name ," Claude sometimes adds a preamble, or an API limit returns nothing but a message. Writing out a response with no PRODUCT: as an article appends the product name as "不明な商品" unknown product to posted-products.log , polluting the next day's deduplication list. A Hatena article titled "Review of an unknown product" is not funny. ② No error text is included — a Claude process killed by timeout can return a short response containing "Request timed out." An API limit produces "rate limit" or "usage limit." Writing that out as an article means post-to-hatena.sh skips it via the grep -qE '不明な商品|Request timed out' guard, and it stays in the Desktop queue until audit-heal.sh cleans it. The guards are layered, but rejecting it in resp is valid is the root-level fix. ③ At least 400 characters — WebSearch sometimes whiffs and returns just a few lines along the lines of "no matching product found." Since one article's worth of Markdown is at minimum 1,500 to 3,000 characters, anything under 400 is a clear failure. This threshold is empirical, and it catches every response too short to be an article. Only when all three conditions are met does it break and move to the next step; if even one fails, RESP="" is set and the attempt counter advances. When all three attempts fail, generate.sh exits 1 without writing a broken article. PRODUCT: line as an I/O contract The most important instruction in the prompt is the constraint: " the first line must contain only PRODUCT: <official product name ." Why does the article need this line at the top? PRODUCT=$ printf '%s\n' "$RESP" | sed -n 's/^PRODUCT: //p' | head -1 BODY=$ printf '%s\n' "$RESP" | awk 'p{print} /^PRODUCT:/{p=1}' -z "$BODY" && BODY="$RESP" -z "$PRODUCT" && PRODUCT="不明な商品" The PRODUCT: line is a separator that reliably splits "product name" from "body" in Claude's response. Even if you make it return a structure of "line 1 is the H1 title, body starts at line 2," a preamble can still slip in. By setting an explicit PRODUCT: marker, awk raises a flag p=1 when it hits the PRODUCT: line and extracts only the lines after it as the body. The extracted PRODUCT does three jobs: it's passed as the keyword to the Rakuten API, appended to posted-products.log to join the next day's deduplication list, and used as the product name for generating the affiliate link. This single line is the starting point for every downstream step. postprocess body performs The post-processing function postprocess body in generate.sh embeds a bit over 30 lines of Python. This is the trickiest part, and it does more than it looks like. First it forcibly normalizes the Markdown structure. lines = body.splitlines title idx = next i for i, line in enumerate lines if line.startswith " " , None title = lines.pop title idx if title idx is not None else f" {product} レビュー" lines = line for line in lines if line.strip not in {disclaimer, contents} No matter which line Claude puts the H1 on, pop lifts it out. If the disclosure text ※本記事はアフィリエイト… or the table-of-contents tag :contents got included twice, they're removed. Finally out = title, disclaimer, contents fixes the first three lines. Whatever layout the body comes back in, the output always starts with "H1 title → disclosure → TOC tag." The next three substitutions are the main event. Substitution ①: replacing placeholders placeholder re = re.compile r"（?▼?楽天で「 ^」 +」を検索してリンク ?:を作成し、ここに貼る|を貼る ）?" body = placeholder re.sub link, body Claude sometimes writes the link as "a placeholder a human should fill in later," in the form （▼楽天で「Roborock S8」を検索してリンクを貼る） . This picks that up and swaps in the correct affiliate link. Substitution ②: replacing Rakuten Markdown links most important rakuten md link re = re.compile r"\ 楽天で「 ^」 」を探す\ \ ^ \ " body = rakuten md link re.sub lambda m: link, body When the prompt says "write it in the format 楽天で「<product name 」を探す <URL ," Claude follows the format, but the URL ends up being Rakuten's ordinary search page URL https://search.rakuten.co.jp/search/mall/... . As-is, that's a non-affiliate link with no tracking. This regex overwrites every Markdown link beginning with 楽天で「…」を探す with the correct affiliate URL. It's the most important substitution — the hb.afl.rakuten.co.jp check in audit-heal.sh passes because this works correctly. Substitution ③: a catch-all replacement for Rakuten-domain links rakuten any re = re.compile r"\ ^\ +\ \ ?:https?: ?// ^ rakuten\.co\.jp ^ \ " body = rakuten any re.sub lambda m: link, body This is the last line of defense for cases where Claude writes a Rakuten URL in some other form inside a comparison table or the summary section. Every Markdown link containing rakuten.co.jp gets unified into the affiliate link. This system has two deduplication logs. posted-products.log — the file that accumulates generated product names. EXCL=$ paste -sd '、' "$LOG" 2 /dev/null -z "$EXCL" && EXCL="（まだ無し）" paste -sd '、' joins all lines into a single comma-separated line and embeds it into the exclusion section of the prompt. If "Roborock S8 MaxV Ultra" is in there, Claude won't pick the same product again the next day. After a few months of accumulation, the "same article shows up again" problem effectively disappears. posted-hatena.log — the file that accumulates file paths already posted to Hatena. if /usr/bin/grep -qxF "$f" "$POSTED LOG"; then continue; fi It combines -x whole-line match and -F fixed string . daily.sh runs three times a day and calls post-to-hatena.sh --all every time. Without this log, the same file would be posted three times. -F is specified so that dots and slashes in file paths aren't interpreted as regex. For the first three days, the audit-heal.sh log looked like this. ==== アフィリ監査 2026-06-03 07:15 ==== --- 本日公開分のカバレッジ --- --- サマリ --- 本日公開: 0本 / 目標: 3本 ｜ 未公開キュー残: 0本 ｜ 非アフィリ: 0本 ⚠ 公開が目標未達（生成 or 公開が失敗した可能性） ❌ 監査NG: 要確認 1件 Zero for three days straight. It should have been computing NEED and calling generate.sh , yet not a single draft had been created on the Desktop. At first I thought "the prompt is bad." I added more product categories and made the output format instructions more detailed. Nothing changed. Next I suspected "maybe it's a tool permission issue" and reviewed the --allowedTools settings. No change. On the night of the third day, I ran daily.sh directly from the terminal. Thirty minutes later, one article was finished. It was failing only via launchd. As I dug into the difference between launchd and manual execution, the comment left in generate.sh after the fix caught my eye. フル記事生成 WebSearch複数回込み は実測で約260sかかる。300sだとlaunchd下で僅かに超えて timeoutにkillされ、全試行が空応答→0本公開になっていた。実測の2倍強を確保する。 GEN TIMEOUT="${AFFILIATE FACTORY GEN TIMEOUT:-600}" Measured 259 seconds → timeout 300 seconds. The margin was only 41 seconds. The flow of generating an article while calling WebSearch three or four times takes about 259 seconds when measured in a terminal. 300 seconds looks like it has room. But a process under launchd carries slightly more startup overhead, and when it overlaps with the 7am hour where WebSearch responses are somewhat slower, 259 seconds can become 305. When timeout kills it, it moves on to the next attempt with RESP="" , and after three empty responses it exits 1. That went on for three days. The fix was just changing the value of GEN TIMEOUT from 300 to 600 . The next morning's log looked like this. ==== アフィリ監査 2026-06-06 07:31 ==== ✓アフィリ | Roborock S8 MaxV Ultra レビュー... ✓アフィリ | Anker SOLIX C800 ポータブル電源... ✓アフィリ | Narwal Freo Z Ultra 実機スペック... 本日公開: 3本 / 目標: 3本 ｜ 未公開キュー残: 0本 ｜ 非アフィリ: 0本 ✅ 監査OK: 3本すべてアフィリリンク付きで公開 Confirming that it works manually is not enough — verifying that you get the same result via launchd is the completion condition for automation. From this lesson I externalized AFFILIATE FACTORY GEN TIMEOUT as an environment variable, so it can be adjusted without touching code. There's also a reflection on "why I didn't notice for three days." When generate.sh returns exit 1, daily.sh absorbs the error with || echo and continues. bash "$DIR/generate.sh" "$i" || echo " daily ⚠ 生成1本失敗（後続の再実行で補充されます）。" That design was a deliberate choice for idempotency: "even if the morning fails, midday refills it." But at the same time it created a blind spot — "even when it fails every single time, processing doesn't stop and no macOS notification goes up." audit-heal.sh fires the notification for 0 articles published at the very end of the process, so the notification wasn't reaching me via launchd when I checked later, they had piled up in Notification Center . keyword is not valid A week after the system started running stably, when an article for the Narwal Freo Z Ultra robot vacuum was generated, the log kept printing generate 商品個別リンクを取得できず検索リンクにフォールバック: Narwal Freo Z Ultra couldn't get individual product link, falling back to search link . Passing keyword: "Narwal Freo Z Ultra" verbatim to the Rakuten Ichiba API returns HTTP status 400. The error body contains the string keyword is not valid . except HTTPError as exc: body = exc.read .decode "utf-8", "replace" if exc.code == 400 and "keyword is not valid" in body: return None → resolve の語削りループへ That return None is the trigger for the word-dropping retry. The single-character token "Z" in "Narwal Freo Z Ultra" was the problem. "Narwal Freo Z" gets rejected too. "Narwal Freo" finally goes through — and then the next problem happens. Searching "Narwal Freo" sorted by review count descending hits the currently most popular model. If that's the "Narwal Freo Ultra," the brand name "narwal" is in the product name, so it passes the brand guard. The original target was "Narwal Freo Z Ultra," yet a link to a different model gets embedded. if not brand or brand in result "name" + " " + result "url" .lower : return result "url" ブランド不一致の判定（ブランド名は合っているが商品名が別物の場合） print f" generate 候補がブランド不一致 {keyword}→{result 'name' :30 } 。", file=sys.stderr return None The current implementation only filters on the brand name the first word . Since it just checks whether the string "narwal" is contained in the result, a different model from the same brand slips through. The hgc fallback URL does carry affiliate tracking, so revenue doesn't go to zero, but the accuracy of individual product links remains an issue. One piece of spec knowledge came out of this problem. The Rakuten API rejects keywords containing single-character tokens with keyword is not valid. Product names with "Z," "S," "X," "i," and similar — common in model numbers — will always trip it. The word-dropping loop in generate.sh is mandatory.With the first launchd configuration, generate.sh never finished no matter how many minutes I waited after the batch started. The claude process existed in the process tree, but nothing was happening. ps aux | grep claude → /Users/xxx/.local/bin/claude -p "..." --allowedTools WebSearch --model sonnet The claude process is definitely there. But it isn't running. In a launchd environment with no tty, the claude command was waiting for input from stdin. In a terminal, user input can be received from /dev/tty , so claude -p decides "no interactive input needed" and proceeds. Under launchd there's no /dev/tty , so it entered a mode of waiting for something to arrive on stdin. RESP=$ timeout "$GEN TIMEOUT" "$CLAUDE" -p "$PROMPT" \ --allowedTools WebSearch \ --model sonnet \ --permission-mode auto \ </dev/null 2 /dev/null </dev/null immediately makes stdin EOF. Adding that one thing stopped the hang. --permission-mode auto was needed at the same time. When using WebSearch, Claude shows a confirmation prompt asking "may I use WebSearch?" In an environment with a tty, a human can type "yes," but with stdin closed via </dev/null there's no response to that prompt and it hangs somewhere else. Specifying auto makes the WebSearch explicitly listed in --allowedTools execute without confirmation. These two flags only work as a set. With only </dev/null , it hangs at the permission prompt. With only --permission-mode auto , it hangs on stdin. Neither one alone solves it. Only with both does it behave under launchd the same way it does in a terminal. Next time, I'll publish the self-healing canaries a happy-path test and a deliberate-failure test I implemented to keep this system running, plus the actual uptime and revenue data readable from three months of logs. The previous chapter covered the three big failures: timeout 300 seconds losing to a measured 259, the stdin hang under launchd, and the Rakuten API's keyword is not valid . Below is a list of the smaller traps I actually stepped on beyond those. They reveal "why it's built this way," so they're also useful as design references if you build your own. macOS wc -l outputs leading spaces This is one of the causes that breaks the idempotency calculation in daily.sh . PUB TODAY=$ find "$ARCHIVE" -maxdepth 1 -name "${TODAY} .md" 2 /dev/null | wc -l | tr -d ' ' macOS wc -l outputs with leading spaces, like " 3" . Without tr -d ' ' , you get NEED=$ TARGET - " 3" - DRAFTS and bash's arithmetic expansion returns an error. GNU Linux's wc has no spaces, so you never notice at all in a local Linux environment — the symptom first appears in the macOS launchd environment. One added line fully resolves it. Without shopt -s nullglob, the glob remains as a literal string In the today's-publications loop in audit-heal.sh , when there are no files for that day: shopt -s nullglob for f in "$ARCHIVE/${TODAY}" .md; do published=$ published+1 done shopt -u nullglob Without shopt -s nullglob , when the glob matches nothing, the pattern string "$ARCHIVE/2026-06-06 .md" itself enters the loop. You can check existence with -e "$f" , but the implementation can end up incrementing the published counter by 1 unintentionally. Always restore scope with shopt -u nullglob when you're done. Applying it globally silently empties other globs. The -x and -F in grep -qxF come as a set if /usr/bin/grep -qxF "$f" "$POSTED LOG"; then continue; fi Without -x whole-line match , /Desktop/アフィリ記事/2026-06-06 071532.md falsely matches as a substring for 071532.md . Without -F fixed string , the . in the path is interpreted as regex "any character." Missing either one still works in most cases, so it's hard to catch in unit tests — it becomes an intermittent failure where double-posting happens only for particular filenames. launchd's PATH is a different thing from the terminal's CLAUDE="${CLAUDE:-~/.local/bin/claude}" BLOGSYNC="${BLOGSYNC:-$HOME/.local/bin/blogsync}" The PATH of a launchd-started process is roughly /usr/bin:/bin:/usr/sbin:/sbin . It doesn't include anything under nvm ~/.nvm/versions/node/vXX/bin/ or ~/.local/bin/ . Even if which claude resolves in your terminal, via launchd the generation phase is wiped out by command not found . Writing defaults as absolute paths and overriding environment differences via .env or EnvironmentVariables is the most reliable design. Drop --publish and drafts pile up on the Desktop, making NEED permanently 0 post-to-hatena.sh -z "$DRAFT FLAG" && mv "$f" "$ARCHIVE/" && echo " hatena アーカイブへ移動: $ basename "$f" " The mv to the archive only happens with --publish . With --draft the default , files stay on the Desktop forever. If a misconfiguration drops --publish , the DRAFTS count keeps piling up on subsequent days and NEED is always calculated as 0. Every day it decides "0 articles need generating," nothing happens, and only audit-heal.sh keeps firing "target not met" notifications. The nasty part is that the symptom is indistinguishable from a timeout failure. Without minPrice: "30000", replacement parts become the link target "minPrice": "30000", "NGKeyword": "中古 訳あり 美品", Searching for "Roborock S8 MaxV Ultra" without minPrice can put replacement dust bags and dedicated cleaning fluid at the top of the review-count ordering. A 30,000-yen floor suppresses false hits on consumables and accessories. The gap versus the prompt instruction of "above 50,000 yen" is headroom for cases where the actual selling price on Rakuten falls below list price. Setting minPrice: "50000" easily produces zero hits for out-of-stock or older models, which increases the frequency of hgc fallbacks. 2 /dev/null makes claude's error messages disappear entirely RESP=$ timeout "$GEN TIMEOUT" "$CLAUDE" -p "$PROMPT" ... 2 /dev/null It's there to suppress stderr noise in the launchd environment, but as a side effect, messages for timeout kills, auth errors, and model errors are all thrown away. When debugging, temporarily change it to 2 /tmp/claude-err.log to see what's actually happening. Be sure to change it back to 2 /dev/null when returning to production. Since the check in resp is valid is the only error-detection mechanism, error content has to be judged from the contents of the response string. A test response without the PRODUCT: separator pollutes the product name PRODUCT=$ printf '%s\n' "$RESP" | sed -n 's/^PRODUCT: //p' | head -1 -z "$PRODUCT" && PRODUCT="不明な商品" "$PRODUCT" = "不明な商品" && echo "$PRODUCT" "$LOG" When feeding a test response directly via AFFILIATE FACTORY TEST RESPONSE , forgetting the PRODUCT: line makes the product name "不明な商品" . Appending to posted-products.log is skipped by the = "不明な商品" check, but the keyword "不明な商品" gets passed to the Rakuten API, leading to keyword is not valid → hgc fallback. An article with an hgc link and a nonsensical product name stays on the Desktop. The first line of a test response must always be PRODUCT: テスト商品名 . Without seconds in the filename timestamp, fast tests collide FNAME="$OUT/$ date +%Y-%m-%d %H%M%S .md" In production each article takes about 260 seconds, so there are no collisions at minute granularity. But with AFFILIATE FACTORY TEST RESPONSE , three articles are generated in seconds when NEED=3. With %H%M minute granularity , the second article within the same minute overwrites the first. Using %H%M%S second granularity prevents collisions even in fast tests. The Rakuten API brand guard lets a different model of the same brand slip through if not brand or brand in result "name" + " " + result "url" .lower : return result "url" brand is the first word of the product name e.g. "narwal" . When "Narwal Freo Z Ultra" drops words down to "Narwal Freo" and hits, the "Narwal Freo Ultra" with the most reviews may be returned. The string "narwal" is contained in both product names, so it passes the brand guard. A link to a different model from the original target gets embedded, but since it's an affiliate link for the same brand, revenue still applies. Fully preventing it requires model-number matching; for now the hgc fallback operates as the final safety valve. Getting the split between set -uo pipefail and || echo wrong stops everything daily.sh set -uo pipefail ... bash "$DIR/generate.sh" "$i" || echo " daily ⚠ 生成1本失敗（後続の再実行で補充されます）。" The set -uo pipefail at the top of daily.sh makes the whole script fail-fast. On the other hand, the generate.sh call absorbs errors with || echo . This split is intentional design, expressing "I don't want to stop the overall flow publishing, auditing , but I'll tolerate individual generation failures." Changing || echo to || true erases the failure message and leaves you unable to tell what happened from the logs. Design principles distilled from more than three months of live operation. 1. Set timeouts to at least 2× the measured value, and externalize them as environment variables GEN TIMEOUT="${AFFILIATE FACTORY GEN TIMEOUT:-600}" Against a measured 259 seconds, 300 seconds is easily exceeded by launchd startup overhead plus morning external API response delays combined. "At least 2× measured, and environment-variable-ized" is the iron rule. You can restart operation by changing one line in .env . No need to touch code. 2. The launchd-specific two-piece set is " </dev/null + --permission-mode auto" Neither one works alone. </dev/null alone hangs at the WebSearch permission prompt. --permission-mode auto alone hangs on stdin. This applies to every situation where you run a CLI in an environment with no interactive input gh , git commit , and interactive-prompting tools in general . 3. Design the idempotent NEED calculation first NEED = TARGET - PUB TODAY - DRAFTS Without the property that "the day's publish count converges no matter how many times it runs," a three-times-daily launchd batch is a breeding ground for double-publishing or over/under counts. Idempotency is the foundation of automation. Failure recovery also collapses into one sentence: "the next batch automatically fills the rest." 4. Defend against broken articles in three stages Stage 1: resp is valid right after generation → Stage 2: grep -qE '不明な商品|Request timed out' right before posting → Stage 3: audit-heal.sh cleanup end of batch . Each stage catches broken articles that got in through a different route. With only stage 1, short responses via test responses or network anomalies slip through. Layered defense looks like overkill, but once you've published a "Request timed out robot vacuum review" to production, you stop hesitating. 5. Cover affiliate link substitution with three variants 置換① プレースホルダー（▼楽天で「…」を検索してリンクを貼る） 置換② MDリンク 楽天で「…」を探す 任意URL 置換③ 楽天ドメイン全般 任意テキスト rakuten.co.jp/... The assumption that "Claude's output will come back in exactly the format you specified" will always be betrayed. By preparing three stages of substitution that unify everything into hb.afl.rakuten.co.jp no matter which format arrives, you reliably pass the final check in audit-heal.sh . 6. Always sanitize macOS wc -l with | tr -d ' ' Make it a habit everywhere arithmetic expansion is involved. If you port to Linux in the future, the diff is a single spot. The cost is zero. 7. The Rakuten API needs three stages: "word-dropping retry → brand guard → hgc fallback" What matters is not giving up on revenue even when you can't get an individual product link. The hgc fallback URL is a search-page link with affiliate tracking; conversion rate is lower than an individual product page, but it passes the hb.afl.rakuten.co.jp check in audit-heal.sh and prevents zero revenue. A design of "always insert some affiliate link and publish" achieves higher uptime than "throw the article away if you can't get a product link." 8. Use shopt -s nullglob with minimal scope Wrap only around the for loop that uses the glob pattern. Applying it to the whole script silently turns intended globs elsewhere into empty arrays. Using it as a set with shopt -u nullglob minimizes the blast radius of the side effect. 9. Absolutely separate the two logs by role posted-products.log holds product names embedded into the prompt with paste -sd '、' . posted-hatena.log holds file paths searched with grep -qxF for exact matches . The formats differ, so merging them into one will definitely break one of the two use cases. Don't give in to the temptation to "simplify." 10. Specify --model sonnet explicitly to pin the cost "$CLAUDE" -p "$PROMPT" --allowedTools WebSearch --model sonnet ... Omit it and Claude Code's default model is used. When the default changes, or a config file changes, you can unintentionally switch to a higher-cost model. Pinning the cost per article lets you predict the monthly bill as "articles generated × cost per article." 11. Verify behavior without API calls using a test environment variable if -n "${AFFILIATE FACTORY TEST RESPONSE:-}" ; then RESP="$AFFILIATE FACTORY TEST RESPONSE" fi Checking postprocess body behavior or debugging Rakuten link substitution doesn't need a 260-second wait and API cost every time. Put AFFILIATE FACTORY TEST RESPONSE="PRODUCT: テスト商品\n タイトル..." into the environment variable and you skip the claude call, verifying downstream processing instantly. This one trick dramatically shortens the development cycle. 12. Make binary PATHs absolute paths that can be overridden by environment variables CLAUDE="${CLAUDE:-~/.local/bin/claude}" Write the default as an absolute path while making it overridable by environment variable. Even if your Mac dies and you reinstall claude, you handle it by changing one line in .env . Hard-coding paths inside the script only troubles your future self. "A system that publishes three affiliate articles every morning fully automatically" is, in the end, a design that moved every decision into four shell scripts. 何を書くか（商品選定）→ generate.sh + Claude どう調べるか（スペック）→ WebSearch どこに投稿するか → post-to-hatena.sh + blogsync ちゃんと動いているか → audit-heal.sh + macOS通知 The cause of publishing zero articles in the first three days was "the 41-second gap between timeout 300 seconds and a measured 259 seconds." That's the sum of launchd startup overhead and morning WebSearch response delays — factors you would never notice with manual execution. "It worked locally = automation is done" is wrong; automation is complete only when you get the same result via launchd . Most of the gotchas introduced here share the common pattern of "works locally, breaks only under launchd." The common thread in the countermeasures is "write with environment differences as a premise" absolute paths, closed stdin, space sanitization, nullglob . Idempotency, layered defense, audit logs. The combination of those three is the actual body of a system that keeps stacking up three articles a day without anyone touching it. I've put the full picture of the system, the breakdown of the 1.2M yen per month, and the 30-day procedure into a paid note → 📕 Claude Code自律環境で、実際どう稼ぐか ― 仕組み・実例・始め方・サポート https://note.com/bokuwalily/n/n849b3a07784a Written by Lily — I ship iOS apps and automate my content stack with Claude Code. Follow along: Portfolio https://bokuwalily.com · X https://x.com/bokuwalily · GitHub https://github.com/bokuwalily